Discussion:
[mapguide-users] EPSG:3857 Changes
Greg
2017-09-28 20:21:19 UTC
Permalink
I've notice that coordinate transformations to ESPG:3857 seem to be a little
off when compared to commercial layers like Google. I have access to high
resolution imagery from Google and it's especially noticeable there.

After a little research I discovered that ESPG:3857 is changing over time,
with its origin moving more than a meter since 1994. according to
http://www.epsg-registry.org the current coordinate system is different than
that used by both Autodesk and Mapguide (v3.1). Based on my experience,
Google must be using the latest version for its imagery.

Does anyone know if this is something that might be addressed, or if there
is a way to manually edit the definition used by Mapguide?

Thanks,

Greg



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html
Greg
2017-10-12 22:40:39 UTC
Permalink
It looks like the cs-map dictionaries may have been updated to solve this
problem since release of MGOS 3.1. See this
https://trac.osgeo.org/csmap/ticket/202
<https://trac.osgeo.org/csmap/ticket/202>

Can anyone tell me how to use the latest with my installation of MGOS 3.1?

Thanks



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html
Jackie Ng
2017-10-13 15:44:29 UTC
Permalink
The asc files mentioned in that changeset are basically the "source code" of
the coordinate system definitions which need to be "compiled" to their
binary .csd equivalents using the CS_Comp.exe compiler tool. This tool is
not bundled with MGOS, so you have to build the tool and dictionaries
yourself from source.

If you have access to the MSVC compiler (you can use the free Visual Studio
2015 community edition, or VS2017 community edition with C++ workloads and
VC140 toolset installed)

Checkout a copy MGOS 3.1 (branches/3.1/MgDev) with Subversion

Go to MgDev\Oem\CsMap\Dictionaries and make the required changes to
coordsys.asc and ellipsoid.asc

coordsys.asc:
https://trac.osgeo.org/csmap/changeset/2753/trunk/CsMapDev/Dictionaries/coordsys.asc
ellipsoid.asc:
https://trac.osgeo.org/csmap/changeset/2753/trunk/CsMapDev/Dictionaries/elipsoid.asc

Go to MgDev\Oem\CsMap\VC140 and open OpenSource.sln in Visual Studio.

Build the solution, which will build and run the compiler that should then
generate updated Coordsys.CSD and Ellipsoid.CSD files in
MgDev\Oem\CsMap\Dictionaries

Copy these updated files over to the CS-Map dictionaries dir of your MGOS
install and overwrite the existing files.

Then restart your MapGuide Server and it should pick up the updated
WGS84.PseudoMercator definition.

Hope that helps.

- Jackie





--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html
Greg
2017-10-17 22:08:47 UTC
Permalink
Jackie,

Thank you for the reply. I was able to create new dictionary files from the
source. The source included the most recent version of the WGS84 Datum and
had been updated 7 months ago. Using the new files didn't make any
difference. My data requires a re-projection from UTM83-12 (NAD83 Datum) to
WGS84.PseudoMercator (WGS84 datum). After a little more research, I learned
CSMap doesn't do any re-projection between NAD83 and WGS84. Initially there
was no difference between the two and this made sense. NAD83 isn't changing
much while WGS84 is moving as it is tied to the International Terrestrial
Reference Frame (ITRF), which changes over time. ESRI has an article about
it here:

I think this may be the cause of my data not lining up with commercial
layers using the WGS84 Datum. Until CSMap does a datum transformation first
and then coordinate translation, things will be a little off.

Thanks very much for your help.

Greg <http://support.esri.com/en/technical-article/000005929>



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html
Continue reading on narkive:
Loading...