Dec 9, 2010 at 12:44 PM

I've been playing around with the Map control as I would like to use it in a project I'm working on, I like it and think it has a lot of promise. There are some things I need to be able to do, some of them may just be because I don't know how to do it, others I think would be very useful features that could be added:

1) Convert between DotSpatial.Topology.Coordinate and lat/lon

I'm sure there must be way of doing this already, however I couldn't find it documented, I could only find a reference in the discussion forum. Basically I need to be able to translate between screen pixels and decimal lat/lons.

2) Programatically move map and set zoom level

I couldn't find any methods to move the map around programatically, in another mapping control I have made, I have methods to set the lat/lon of the centre of the map, and to set the zoom level. I see there are zoom in/out methods already.

3) Properties to get topleft / bottomright and centre coords of the current map

I think I can get these values only in event handlers at the moment

4) Event that fires when map has changed in any way

I see there is an event called ViewExtentsChanged, maybe this is similar to what I need?

5) Use .NET 4 client framework, not full framework

I mentioned this yesterday, just adding it here it here for completeness. 


1 and 2 are really important for me, if anyone has could tell me how to do this already that would be great. Otherwise, I think these would be great additions.


Dec 9, 2010 at 1:38 PM

I'll take a crack at some of these:

  1. I assume you mean converting between world map coordinates of the map and screen pixels.  World map coordinates could be lat/lon, but it really depends on the projection you are working in.  Use Map.PixelToProj and Map.ProjToPixel to convert between screen and map coordinates.
  2. You can set the Map.ViewExtents to change the map coordinates extent you are viewing in the map.
  3. Same as 2.



Dec 9, 2010 at 3:12 PM
Edited Dec 9, 2010 at 3:15 PM

Great responses Kyle.  It sounds like his projection might not be geographic, however, and he might also need help getting from say UTM coordinates into WGS84 coordinates.  For that you should use the Reproject functionality.  If you have your coordinates in a FeatureSet, you can use myFeatureSet.Reproject(KnownCoordinateSystems.Geographic.World.WGS1984);  {that was from memory but it should be something reasonably close to that.  It will require a reference to DotSpatial.Projections.}

If you don't want to work with a featureset, you can organize your coordinates into an array of doubles: like:

double[] myPoints = new double[] { x1, y1, x2, y2 };

Then, with that array, you simply call:

DotSpatial.Projections.Reproject.ReprojectPoints(myPoints, 0, myPoints.Length/2);

Anyway, I hope that clears up confusion rather than making things more confusing.


P.S. "WGS84" = lat, long.

Dec 10, 2010 at 1:23 PM

Ok, thanks both of you, much of this is unfamiliar to me, I have a reasonable amount of experience writing mapping software, but in my tiling engines (i.e. OpenStreetMaps) I use decimal lat/lons for everything.

Am I correct in saying that if I, for example, import some image data using the WGS84 coordinate system, in the Map.GeoMouseMove event handler, the e.GeographicLocation.x and y are lat/lon values, but in UTM format? Is there some way to make it give me decimal lat/lon values?

Dec 10, 2010 at 3:50 PM

There are really only two systems.  One is the "pixel" system.  0,0 is the top left hand corner of your map.  When you intercept a mousemove event args on windows forms, the X and the Y are in pixel coordinates relative to that form or control.  The e.GeographicLocation.x and e.GeographicLocation.y represent the result of taking those x and y pixel coordinates and transforming them into geographic coordinates.  If your data is in WGS84, then x is longitude and y is latitude.  In other words, if you look at e.GeographicLocation.x and it falls in the expected range from -180 and 180, you are probably good to go. 

The thing is, depending on your projection, those geographic coordinates may not be Lat Long.  The reason I suggested that you might need to reproject the data source is if your e.GeographicLocation.x and y are not lat/lon, (that is not the numbers you were expecting to see that range from -180 to 180 or -90 to 90) then you might be fooled into thinking that you are working in some kind of pixel coordinates, but you are not.  You are working in a "projected" coordinate system.  A map projection is a mathematical trick for converting angular measurements into a flat euclidean plane.  By default, if you just use longitude as X and latitude as Y, that is called the mercator projection.  While technically this is ok for many people, it introduces distortions that might not be desirable, especially near the north and south poles.  So there are lots of alternatives out there.  In reality, if you have a data source that is a shapefile from the United States that isn't in lat, long, then you could be working with UTM (Universal Transverse Mercator), or a State Plane system (which have different projections but are optimized for a very small location), or some kind of conic projection.  In any of these cases, the numbers for e.GeographicLocation.x  would most likely increase from left to right and e.GeographicLocation.y should most likely increase from the bottom to the top of the map (which is not the case with pixel coordinates).  Also, these other projections tend to use distance units of feet or meters.  Therefore, expect the numbers to be very large.  It is not uncommon to have coordinates in the range of 4 million or so for Y in a UTM projection.

Images can introduce another element to the problem.  A simple bitmap, for instance, has no idea where it is spatially.  Most image formats can be supplemented with what's called a world file.  In the case of a jpg, for instance, the world file would be a text file with the same name as the image, but would end in .jgw, or possibly .wld.  The convention is to take the first and last letters from the original extension and to add w for the final character.  If this file does not exist, and your image is not a very special geographic image format, like a geotiff, which contains internal tags for geographic referencing, then you may end up with an image that just goes from 0 to width in pixels and uses that as the default location on the map.  If you know where your image is supposed to be, you specify the location and cell size in your world file in order to ensure the image shows up in the correct location.  I need to set up some simple image positioning tools for DotSpatial.

See also our very introductory DotSpatial page on images images




Dec 13, 2010 at 1:02 PM

Thanks for explaining that, using some example shape files it does work how you exaplain and how i was expecting. What is confusing me is that some geotiff files are not working as expected, when loaded they come up with the "Invalid or missing projection" dialog, and then i select the WGS1984 option, but as you suggest, it uses the pixels as location on the map because the projection details are obviously not found. This geotiff for example doesn't work as i was expecting.

Also, is there a way to make it always use decimal lat/lon as the coordinate system, i.e. if the incoming data is not in the desired projection, then reproject it by default?

thanks, Martin.

Dec 13, 2010 at 3:18 PM

At this point, as long as you are working with a recent release or source code, the data objects themselves (FeatureSet, Raster, and ImageData) all should support a "Reproject" method which you can use.  The layer will also support the reproject option.  If you are working with a raster and need to reproject it, I recommend either reprojecting it before adding it to the map as a layer, or reprojecting the layer after its in the map.  Once the layer exists, the image representation of the raster is also georeferenced, and needs to be synchronized.  So reprojecting the raster might not reproject the grid.

The geotiff support is currently coming from GDAL, but I have also seen some cases where ecw or other formats don't consistently get represented correctly from the projection standpoint.  It's possible that there are some options open to us to investigate there, but for the time being, if you have a ".prj" file representing the projection, you can open that in code using a ProjectionInfo class with the "ReadEsriString" method.  Then you can "define" the projection manually, that is "myImageData.ProjectionInfo = myProjectionInfo"

This does not reproject, but only defines what projection the coordinates already are.  Combined with the world file that translates row and column values into coordinates, this gives complete control of where the image is.