[ gpsdrive ] Patches

[Jan-Benedict Glaw]

On Fri, 2008-12-19 10:55:05 +0100, Guenther Meyer <d.s.e at sordidmusic.com> wrote:
> Am Freitag 19 Dezember 2008 schrieb Paul Martin:
> > On Fri, Dec 19, 2008 at 08:31:19AM +0100, Guenther Meyer wrote:
> > > Am Donnerstag 18 Dezember 2008 schrieb Paul Martin:
> > > > > mapnik projection:
> > > >
> > > > That's this one:
> > >
> > > see hamish's statement...
> >
> > The reason is that without this fix, the osm.xml file disagrees with what
> > gpsdrive requests, and all your roads are drawn about 50km closer to the
> > equator than the correct position. The closer to the equator your location,
> > the less the offset.
> >
> I agree that the projection used in the xml file has to be matched with the 
> one in the mapnik initialization.
> 
> > This projection is also the default used by the current osm2pgsql "SVN
> > version 0.55-20081217 $Rev: 10464 $".
>
> but exactly this is the problem. it's the CURRENT projection used.
> they already changed it some time ago, which led to the problems we have now.
> what if they change it again? adapting a fixed projection to every change of 
> osm2pgsql's projection seems to be senseless work.

I was one of those who spoke up the last time this changed.

As I know right now, the point was to build OSM with Google Maps in
mind. At the beginning, they thought that Google Maps used the
ellipsoid mercator projection, but as it came out at later
comparisons, Google uses its own projection now known as "SRID"
900913, leet speech for GOOGLE. It's the famous "spherical mercator"
projection, where we simply assume the earth to be a simple sphere.

osm2gpsql used to use whatever was default at some time. In its early
days, this was true mercator projection (with an ellipsoid), later on
spherical mercator.

> > Agree on a projection, then use it consistently.
>
> this is dependending on osm2pgsql.
> we also could use our own copy of osm2pgsql with a fixed "gpsdrive" 
> projection, but that seems also to be stuid.

Stupid.

There might be a simple way:

> the best way would be reading the used projection from the database, but that 
> has to be done by someone who knows how to get this information out of the 
> postgis database.

gis=> select proj4text from spatial_ref_sys where srid=(select srid from geometry_columns where f_table_name ='planet_osm_point');
                                                    proj4text                                                     
------------------------------------------------------------------------------------------------------------------
 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
(1 row)


It's quite simple. All those GEOMERY columns simply save three numbers
(usually, the third one, altitude, is ignored) without any meaning.
There's no indicator whether this is some Gauss-Krüger pair, Lon/Lat
etc.  However, for every GEOMETRY column, there's an entry in the
`geometry_columns' table, describing how to interpret those numbers.

We can simply query the column's SRID and thus the stored Proj.4
string.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:          GDB has a 'break' feature; why doesn't it have 'fix' too?
the second  :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.gpsdrivers.org/pipermail/gpsdrive/attachments/20081219/f69171ec/attachment.bin>