PTV Group - Logistics Forum

We are implementing our Transport Management System at a new customer. This customer has his addresses already Geocoded in Lat/Lon format. Our transport management solution uses the xLocate feature to GeoCode addresses and xMap to plot them on map etc. The customer asked how to convert his geocodings (done by a paid service provider) to PTV Mercator format?

This code snippet on the web https://gist.github.com/oliverheilig/7029947 lead me to the PTV Spherical Mercator actually is the EPSG:505456 format. With a freeware tool http://www.linqpad.net/download.aspx I was able to migrate based on the formula provided in the code snippet.

So far the testing results are quite positive. Is this the preferred way of handling this? Or are there more intelligent features in the xServer suite capable to convert? Of course we could simpy re-geocode the addresses but then we would loose all the information and work already put in the geocoding. From the other side, when calling the geocoding again, you are sure all addresses are correct against the current map...

The xServer supports the uses of many coordinate formats. The Mercator projection you are describing is just the default.

If you want to use another coordinate format You need to add a CallerContextProperty to your CallerContext. Set the key to "CoordFormat" and the value to your desired format. For an example how to setup the callercontext see our basic mapping example. The caller context mechanic applies to all xServer request, not just the mapping.

For legal values you can have a look at the CoordFormat enumeration in our API documentation . Note that for common used format we have a text value like OG_GEODECIMAL (WGS84) but you can also use OG_SRID if you are using an exotic format.

Looking at your post you most likely want to use the the OG_GEODECIMAL format.

Now the question is what is the correct coordinate format for you? This often does not depend on the core xServers but mostly on what your software can handle / prefers. Sticking to OG_GEODECIMAL because you have a service that works with this format is a nice choice, it saves you from writing unneeded code.

The reason why we have Mercator as a default is because it is easier "screen pixel" to "real world coordinate" since Mercator has projected out the curvature of the world. This used to be a huge benefit when building your own software for visualizing map solutions. At current time most customers do no develop the visualization from scratch but tend to use mapping controls like our PTV map control for .net winform and WPF or Leaflet for web applications. These controls take care of a lot of internal calculations so you can use the format you want to.

Hello Joost, Jerome,

@Joost: thanks for your support

Let me just add one more aspect to this:

The decision between "regeocode all addresses" versus "recycle / transform existing coordinates" is influenced by the quality of the existing coordinates: if they are on a high level, e.g. manually repositioned I recommend to recycle them and just geocode the new addresses based on the coord format of the application itself.
This is possible because single objects do not "move" so POIs and customers ... won't change that way.
If the existing coordinates are poor (e.g. automatically geocoded, based on street detail or even district only - no housenumber level) it is helpful to geocode them again.

What is more important: in the context of routing it is sometimes necessary to recompute distance matrices after a map update (or change of basic provider data), e.g.if you want to use them as reference matrix: if you computed all your driving times/distances based on an old street network and new streets have been added in the new version this has a bigger impact, especially in areas of housing estate.

Let us know whether you are happy with this info,

Best regards to Kloten,
Bernd