EPSG and the "Popular Mercator"

[Eric Blasenheim]

Rather than continue to tack onto a thread that was originally about
PostGIS, I thought I would respond under a new heading.

A couple of comments:

Thanks to Warren, PBBI is now aware that EPSG has for some reason
deprecated 3785 and now wants us to use 3857! I will try to find out
what went on there but in my opinion this is a bit irresponsible of
them. Anyway,thanks for the heads up and I owe him a beer.

The important point is that version 10.0 will support the projection
completely with its own appropriate MapBasic string.

As many of you know, we only associate a coordinate system string with
a code in the .PRJ file and there is a one to one correspondence
there. So currently you can't have two codes for the same thing. In
most cases in Professional, you will never use the code but there
could be an issue with geotiffs. If you are registering images such
as .PNG the true system will just be in the .TAB file associated with
it. Again, the code will not matter.

As for the question about working with PostGIS or any other database,
yes it will be important to use the correct EPSG code at the database
level as I believe both PostGIS and SQL Server store EPSG codes at the
geometry level. That is probably the most important reason why we need
to figure out this silly number argument. As for SQL Server, this
code, not being "Geographic" will not be checked by the system from
what I know. I am not as sure about PostGIS.

This assumes, of course, that people will be creating data in this
system. One of the stranger things, again in my opinion, about all
this is that the standard system for all user data for Google or
Microsoft Virtual Earth is still Lat/Long WGS84! All the data produced
by TeleAtlas and other vendors is still in that system which means it
is in degrees whereas data the "Popular Mercator" is in meters. It is
true that if you are generating map images in Popular Mercator from LL
data that an on the fly reprojection will occur. But I would not go
headlong into storing my data in this system. My two cents.

As for 900913, I stand by my statements and formally announce my
disagreement with my friend (I think) Lars!

Firstly, Google did not create it. It was created by some late
nighters wanting to adapt Open Layers to Google maps and Open Layers
requires EPSG codes. So they made one up because EPSG is slow and
thumbed their noses originally at the Spherical (non-elliptical)
Mercator!

EPSG eventually got their act together and accepted reality and came
up with a code. Why they are changing it now I have no idea.

EPSG also supports the concept of custom codes! So 900913 is just a
custom code. So why am I complaining!

Because custom codes are about non-interoperability. They just work
for your system! Standards exist for a very simple reason. They allow
us to interoperate and hopefully concentrate on more important things.
We have much bigger problems to solve than what code we assign to
something.

A good example is XML. From a visualization perspective, the software
world grew up from its US only perspective and starting supporting
numbers with commas as decimal and regional settings of all types! But
when it came to the transfer of data, W3C did a great thing and said
this makes no sense for data and came up with one way of representing
numbers! In retrospect, they probably should have made the standard
the European way so that all the bugs in software would have come out
that much quicker.

Nevertheless, there is a standard, it solves a problem and we can get
back to doing real work!

While public acceptance may one day force us to support 3785, 3857 and
900913, is that what you really want to have us coding and testing?
Wouldn't we all rather just get back to solving real problems!

I will post back anything I can find on the issue and what our plans
are.

Eric Blasenheim
Pitney Bowes Business Insight