I am having trouble displaying country borders properly in GeoServer, as you can see from the link below (map of Italy).
http://trideg.server.de/tridec/wms?service=WMS&version=1.1.0&request=GetMap&layers=tridec:static_hasc_regions&styles=&bbox=489196.9,4109254.4,2426416.9,5987770.7&width=775&height=330&srs=EPSG:900913&format=application/openlayers&viewparams=codes%3A%27IT%27
The problem occurs with country boundaries which have very sharp edges (I assume), e.g. the shape of Albania shows correctly:
http://trideg.server.de/tridec/wms?service=WMS&version=1.1.0&request=GetMap&layers=tridec:static_hasc_regions&styles=&bbox=489196.9,4109254.4,2426416.9,5987770.7&width=775&height=330&srs=EPSG:900913&format=application/openlayers&viewparams=codes%3A%27AL%27
I obtained the ESRI shapefile from naturalearthdata.com and used ogr2ogr to transfer them in a database, which GeoServer uses as a datasource and created a layer in it.
Anyone has a lead? Either I missed something in the layer configuration (the projections are alright though, as the shapes are positioned correctly in the map), or ogr2ogr messed up the data during the conversion.
This looks like the common problem that is caused by how different products create polygons. Some products insist that the first and last point of a polygon must be the same co-ordinate whereas other products will automatically close the polygon from the last co-ordinate to the first.
From the Geoserver documentation it requires that polygons have the same first and last co-ordinate. I would recommend that you edit the polygons in the shape file to accomplish this.
You could use ArcMAP, Quantum GIS or FME off the top of my head to do the conversion.
Related
I was wondering if it were possible to extract coordinates from a static map picture like this:
Is it possible to extract the coordinates of the routes? The only idea I can come up with, other than manually getting them by hand, is by overlaying the map and extracting the exact coordinates that way.
The process that you are looking for is called georeferencing in a GIS context.
In order to determine the latitude/longitude coordinates of a point (or series of points in a line), you need to first establish coordinates of other known points. These are reference points of known locations (such as a distinctive coastline, or a city). Applying these to the raster image that you have, you can then overlay it on a map in a GIS application and then query other unknown locations on the image (such as the routes) to establish their latitude/longitude.
You could attempt this in a graphics program by looking at the x/y coordinates of the route pixels and compare to a known reference point pixel; however, the math on that is going to be tedious and you also wouldn't account for the map projection. Both of those are taken care of by georeferencing.
I would note that you should consider the results you get, even in a well-referenced GIS, to be approximate. The map deals with a very large spatial area, and the routes cover long distances. But since it dates from 2012 it was presumably made in a GIS application and so at least the source data is likely to be accurate :)
Additional resources:
Help Page for ArcGIS (both overview and instructions)
Help Page for QGIS (tutorial)
I need to generate a DEM (10m Cell Size) of the entire coastline for South Africa. I've tried to generate it within ArcGIS, but the Annudem Algorithm that ESRI is currently using within Top To Raster is not capable of generating my DEM.
Please can anyone let me know firstly if GRASS GIS can handle DEM's this large (i.e. millions of cells) and can use shapefiles: Contours; PointElevation and Coastline Mask.
Can anyone give me the necessary steps required to accomplish the following within GRASS GIS.
Please note that I've never used GRASS before.
Regards
Peter Wilson
Grass GIS CAN handle large DEM`s though I am not 100% sure about so huge territory. I can suggest you to divide all territory in subregions and process them separately and later on make mosaic using r.patch
In short, here is how I`d do.
All commands you can either find in GUI or launch writing them in console.
Prepare/Set up location and coordinate system for your desired place, e.g. South Africa
Upload your vector files using v.in.ogr . You can use GUI.
Upload your mask file.
Load uploaded vector file in map view display and right click in map list display and choose - set region from display (or something similar)
Use g.region and set your resolution (res=10) (actually here also you can set region from loaded raster or vector map)
If your mask is in vector format, convert it to raster file using v.to.rast giving any masking value, 1 or 9999 for example. You can use GUI.
Set the mask with r.mask and define previously set value. This is where I suggest to use console but I guess GUI also could work out well.
If you have multiple vector maps (points, lines) with values, you have to join them in one composite vector map using v.patch, but before doing it...
make sure all of them have equal column name where values are stored. If neccessary, for each loaded vector map rename column in which you have your values using v.db.renamecol. Now you can launch v.patch with "copy also attribute table" option so now you have composite vector map altogether which you`ll use for DEM generation.
Now all pre-works are done and continue with r.surf.rst or r.surf.idw or any other algorithm which takes values from specified column in your patched altogether vector map and generates that DEM.
Here you can find some specs about each DEM generation algorythm
I've been playing with Mapbox's blog post about converting heat maps to contour lines, and I'm stuck at the extraction part of this process.
I used the CSV plugin to create a vector layer of points, then a heat map raster layer based on that, but I can't seem to be able to see the contour lines based on that raster layer after that. When I looked at the properties and selected categorized, it didn't seem to have any symbols listed.
I'm guessing this is probably some kind of type error since I had to create the raster layer based off of map units and not meters, but I don't know how to correct it. What am I missing?
Okey dokey. After the holiday weekend I figured it out.
It was basically a type error with the CRS. Although it's not explicitly stated, I got in touch with MapBox and found out they were working in Google Mercator. It's also a perfectly acceptable CRS to use when you eventually have to import the .shp file into MapBox/Tile Mill.
I have a few hundred GPS coords stored in a mysql DB. They are of major cities across the globe. I need to put these points on a map, with a 100km semi-transparent radius circle around each point.
How does one go about doing that?
Try KML. It uses tags, in a fashion similar to XML, to create objects that can be imported into Google Earth. You may want to create <Geometry> objects consisting of a <Point> and a <LineString> for each of your locations. Since it is not possible to draw a circle directly, you will have to define many points that are equidistant from the city to create something that looks like a circle.
Use whatever glue language you prefer for parsing the coordinate data from your DB and generating a KML file. It should be fairly straightforward once you've figured out how to do it with one data point.
I am trying to take a shapefile of subdivisions within a county that I have created and line it up with another shapefile that was given to me by the County Appraisal District (parcel data). When I try to get them to line up then my streets shapefiles is not aligned with everything else. They are all on the same coordinate system and I do not want to have to recreate the shapefile for the subdivisions. Any thoughts?
This is a question with answers that may be simple or may be very complex, depending on your situation. As a GIS developer, I've most commonly seen this as a symptom of an incorrectly defined coordinate system. However, whether this is the case or not, and what the solution is strongly depends on your environment. From here on, I'll assume that you're working in an ESRI package...
I agree with the other posters that your problem is one of mismatching projections and/or datum definitions.
The most important thing to understand as regards projections in ESRI software is this:
Manually setting the projection of a dataset (shapefile, geodatabase feature class, etc) in ArcCatalog does NOT reproject that dataset!!!
In order to reproject your data, you must EXPORT the data from an ArcMap session in which you've been working and where the data is obviously lined up correctly. During the EXPORT, you are given the choice of saving your data with the coordinate system of the underlying map or that of the original dataset.
Your best bet is to follow these steps to create a new dataset with the correct projection and then extrapolate what you need to do to fix your specific problem:
Create a new ArcMap session and set its coordinate system:
Do this in a fresh ArcMap session with NO OTHER DATA. Be sure to explicitly set the coordinate system of the ArcMap mapview to your desired coordinate system (I recommend the one that matches the data you're trying to overlay, or one from another well-established dataset).
Add one other dataset with a known good coordinate system.
Create your new dataset in this ArcMap session. Give your new data the same coordinate system as the ArcMap mapview and the one other dataset in the map. Set the XY domain of the new data to exceed the area defined by your other dataset, but don't go beyond the size that will reduce your desired spatial resolution.
Create your data. It can be any data at this point. Some lines, some polygons, etc. Save your work.
Export your new dataset. When prompted, choose to save with the coordinate system of the underlying mapview.
Create a new ArcMap session and add your new dataset. Then add your parcel dataset. They should now occupy the same space in your map window.
Edit your new data to your heart's content.
Some probable issues if this doesn't help:
You didn't follow these steps correctly - check the ESRI documentation; this is a well documented issue.
The parcel data you're trying to match doesn't have properly defined coordinate system. It's always possible that the keepers of this data don't know what they're doing and have munged it up. I've seen this problem more times that I care to admit.
You've matched the projection but have mis-matched the datum. Many municipalities are still using data in NAD27, which is way out of date. Some have moved to the modern NAD83. The difference can be up to 300 meters, depending on where in the country you are. Also, data that originates from surveying or GPS equipment is usually collected in WGS84 (the typical default for satellite surveying), which is for all practical purposes the same as NAD83, at least at mapping scale resolutions.
Try researching these issues and see how it goes. I'll say it again:
Manually setting the projection does NOT actually project that data!!
Good luck!
Your problem is probably one of projection
| projection: character string that names a map projection to use. See
| 'mapproject' (in the 'mapproj' library). The default is to
| use a rectangular projection with the aspect ratio chosen so
| that longitude and latitude scales are equivalent at the
| center of the picture.
`-----
Agree that your problem is projection. Is there a .prj file extension associated with either of your files? If not key first is finding out what projects you have. I would guess State Plane of some sort if you are dealing with U.S. centric local data from a local government.
Cadastral tools (surveyer tools) usually let you specify a handful of control points and will then "warp" the data to fit to your control points. This can be anything from a simple shift to something more complex. If everything is shifted by a few feet, you can also just use your "editor" to select all shapefiles and then move them however many feet necessary.
If you've verified that both shapefiles are using the same coordinate system, then projection is less likely to be the problem. It's fairly common for parcel data to be "offset" from other data sources (such as roads). This comes from inconsistent collection methods and points of reference.
Another source of error can be that one of the shapefiles has the wrong coordinate system specified. For example, if the roads were actually WGS 1984, but it's prj is set to NAD1983, you will see some significant errors. This usually happens if you had to manually set the coodinate system for a shapefile (i.e. it didn't include a PRJ and you created one).