Mapnik Projection used by gpsdrive
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
Mapnik Projection used by gpsdrive
by Jan-Benedict Glaw
::
Rate this Message:
Hi!
Some time ago, I started another small GTK+ project[1]displaying Mapnik rendered cards. (Aimed at helping OSM tagging amenities like post boxes, public phones, ...) I started off gpsdrive's mapnik.cpp and used gpsdrive's osm.xml initially. These days, I tried to use current OSM's osm.xml file, which is quite similar to gpsdrive's version (so that I guess it was a copy at some time.) However, that didn't work, because Debian's old version of osm2pgsql didn't convert the [power_source] tag, which led to Mapnik not displaying basically all of the amenity layer. After updating osm2pgsql to the SVN version, I was able to use my app with it, but the card display was quite off. Projection seems to have changed. Gpsdrive used to use "+proj=merc +datum=WGS84", whereas OSM (and the default settings of osm2pgsql; the old behavior can be forced with the `-M' switch) uses "+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 +over". I'd like to file a bug report for osm2pgsql, but gpsdrive would need to either touch the docs (add -M to the osm2pgsql call) or change its projection method. (And if gpsdrive wants to follow osm.xml, it would need the new osm2pgsql, too, to get the additional table column referenced there.) What are your suggestions in this case? MfG, JBG [1] wget http://lug-owl.de/~jbglaw/gpsdisplay/gpsdisplay-latest.tar.gz git clone http://lug-owl.de/~jbglaw/gpsdisplay.git -- Jan-Benedict Glaw jbglaw@... +49-172-7608481 Signature of: Zensur im Internet? Nein danke! the second : _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
|
|
Re: Mapnik Projection used by gpsdrive
by Jan-Benedict Glaw
::
Rate this Message:
On Thu, 2008-09-18 19:02:07 +0200, Jan-Benedict Glaw <jbglaw@...> wrote:
> After updating osm2pgsql to the SVN version, I was able to use my app > with it, but the card display was quite off. Projection seems to have > changed. Gpsdrive used to use "+proj=merc +datum=WGS84", whereas OSM > (and the default settings of osm2pgsql; the old behavior can be forced > with the `-M' switch) uses "+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 +over". > > I'd like to file a bug report for osm2pgsql, but gpsdrive would need > to either touch the docs (add -M to the osm2pgsql call) or change its > projection method. (And if gpsdrive wants to follow osm.xml, it would > need the new osm2pgsql, too, to get the additional table column > referenced there.) compatibility with regular osm2pgsql installations off OSM SVN... MfG, JBG -- Jan-Benedict Glaw jbglaw@... +49-172-7608481 Signature of: The real problem with C++ for kernel modules is: the second : the language just sucks. -- Linus Torvalds _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
|
|
Re: Mapnik Projection used by gpsdrive
by Christoph Metz
::
Rate this Message:
|
|
|
Re: Mapnik Projection used by gpsdrive
by Christoph Metz
::
Rate this Message:
|
|
|
Re: Mapnik Projection used by gpsdrive
by hamish_b
::
Rate this Message:
|
|
|
Re: Mapnik Projection used by gpsdrive
by Guenther Meyer
::
Rate this Message:
Am Sonntag 21 September 2008 schrieb Christoph Metz:
> i don't know who is always changing this. i have to look in the svn > log but the second projection is correct. > really? maybe they changed something in mapnik/osm2pgsql? my current gpsdrive version had used the second projection (the one with the long string), leading to a displacement of the rendered map of several kilometers. atfer switching to the other (wgs84) projection, the map seems to be right... is it possible to read the used projection directly from the database instead of using a fixed one? _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
|
|
Re: Mapnik Projection used by gpsdrive
by Christoph Metz
::
Rate this Message:
|
|
|
Re: Mapnik Projection used by gpsdrive
by Christoph Metz
::
Rate this Message:
|
|
|
Re: Mapnik Projection used by gpsdrive
by Jan-Benedict Glaw
::
Rate this Message:
On Mon, 2008-09-22 15:37:01 +0200, Guenther Meyer <d.s.e@...> wrote:
> Am Sonntag 21 September 2008 schrieb Christoph Metz: > > i don't know who is always changing this. i have to look in the svn > > log but the second projection is correct. > > > really? > maybe they changed something in mapnik/osm2pgsql? osm2pgsql was changed. The "old" version wrote something that's compatible with the "short" projection string, while up-to-date versions (eg. *not* those of the osm2pgsql Debian package....) write something that's compatible with the "long" string. The newer osm2pgsql versions can also behave like the old versions, if the "-M" command line option is used. But since OSM switched, I think the best way for gpsdrive would be to also use the "new" scheme and to force users to update their databases, caches and osm2pgsql. The benefit would be that they only need one database for general OSM/Mapnik use and gpsdrive, instead of two. (Or fiddle with projection parameters.) As a side note: If you use (or want to follow) the *current* osm.xml from OSM SVN, you'll loose the amenity layer (eg. parking places, recycling boxes, ...) because the current osm2pgsql's default.style converts an additional column, which is missing from the old version and required by up-to-date osm.xml files (from SVN). Unfortunately, Mapnik fails quietly if a filter references a non-existing column and doesn't draw the whole layer. (And my missing C++ skills won't really allow me to work on that.) MfG, JBG -- Jan-Benedict Glaw jbglaw@... +49-172-7608481 Signature of: "Debugging is twice as hard as writing the code in the first place. the second : Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
|
|
Re: Mapnik Projection used by gpsdrive
by Guenther Meyer
::
Rate this Message:
Am Dienstag 23 September 2008 schrieb Jan-Benedict Glaw:
> On Mon, 2008-09-22 15:37:01 +0200, Guenther Meyer <d.s.e@...> wrote: > osm2pgsql was changed. The "old" version wrote something that's > compatible with the "short" projection string, while up-to-date > versions (eg. *not* those of the osm2pgsql Debian package....) write > something that's compatible with the "long" string. The newer > osm2pgsql versions can also behave like the old versions, if the "-M" > command line option is used. > > But since OSM switched, I think the best way for gpsdrive would be to > also use the "new" scheme and to force users to update their > databases, caches and osm2pgsql. The benefit would be that they only > need one database for general OSM/Mapnik use and gpsdrive, instead of > two. (Or fiddle with projection parameters.) > they will change it? so the best way is to read the projection from the database, if possible, or to store it somewhere on database creation. > As a side note: If you use (or want to follow) the *current* osm.xml > from OSM SVN, you'll loose the amenity layer (eg. parking places, > recycling boxes, ...) because the current osm2pgsql's default.style > converts an additional column, which is missing from the old version > and required by up-to-date osm.xml files (from SVN). additional column? which one? so osm2pgsql won't create the amenity column anymore? > Unfortunately, > Mapnik fails quietly if a filter references a non-existing column and > doesn't draw the whole layer. > that's bad. I mean, we don't need mapnik to draw those data, because gpsdrive has its own layer for that. but failing and drawing nothing is really bad... _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
|
|
Re: Mapnik Projection used by gpsdrive
by Jan-Benedict Glaw
::
Rate this Message:
On Tue, 2008-09-23 14:46:32 +0200, Guenther Meyer <d.s.e@...> wrote:
> Am Dienstag 23 September 2008 schrieb Jan-Benedict Glaw: > > On Mon, 2008-09-22 15:37:01 +0200, Guenther Meyer <d.s.e@...> > wrote: > > osm2pgsql was changed. The "old" version wrote something that's > > compatible with the "short" projection string, while up-to-date > > versions (eg. *not* those of the osm2pgsql Debian package....) write > > something that's compatible with the "long" string. The newer > > osm2pgsql versions can also behave like the old versions, if the "-M" > > command line option is used. > > > > But since OSM switched, I think the best way for gpsdrive would be to > > also use the "new" scheme and to force users to update their > > databases, caches and osm2pgsql. The benefit would be that they only > > need one database for general OSM/Mapnik use and gpsdrive, instead of > > two. (Or fiddle with projection parameters.) > > that's right. > but it's not a good solution to use a fixed projection. who knows how often > they will change it? > so the best way is to read the projection from the database, if possible, or > to store it somewhere on database creation. A quick look at the osm2pgsql code tells me that this isn't stored anywhere, but I may be wrong. Though, it probably would be nice to add another table with at least the used SRS, or even the whole projection string. > > As a side note: If you use (or want to follow) the *current* osm.xml > > from OSM SVN, you'll loose the amenity layer (eg. parking places, > > recycling boxes, ...) because the current osm2pgsql's default.style > > converts an additional column, which is missing from the old version > > and required by up-to-date osm.xml files (from SVN). > additional column? which one? so osm2pgsql won't create the amenity column > anymore? `power_source' was added. It's referenced in the filter rule for electric generators based on wind mills. But this seems to break generation of the whole Mapnik layer. > > Unfortunately, > > Mapnik fails quietly if a filter references a non-existing column and > > doesn't draw the whole layer. > > that's bad. > I mean, we don't need mapnik to draw those data, because gpsdrive has its own > layer for that. but failing and drawing nothing is really bad... I'd like to get some box to test Mapnik SVN vs. released 0.5.1 version (as of Debian's packages). Maybe that bug is even fixed, but I *try* to only install software with Debian packages. If anybody of you has Mapnik SVN installed, please modify one filter rule (in osm.xml) to reference a non-existing tag name (each tag name is converted to a SQL column.) If the layer fails to draw, current SVN Mapnik is still buggy. (I suggest modify one of the amenity rules and s/amenity/amenity_not_in_database/ and just try to find a Parking symbol :) MfG, JBG -- Jan-Benedict Glaw jbglaw@... +49-172-7608481 Signature of: 17:45 <@Eimann> Hrm, das E90 hat keinen Lebenszeit Call-Time Counter mehr the second : 17:46 <@jbglaw> Eimann: Wofür braucht man das? 17:46 <@jbglaw> Eimann: Für mich ist an 'nem Handy wichtig, daß ich mein Gegeüber hören kann. Und daß mein Gegenüber mich versteht... 17:47 <@KrisK> jbglaw: was du meinst ist wodka. 17:47 <@KrisK> jbglaw: es klingelt und man hört stimmen _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
|
|
Re: Mapnik Projection used by gpsdrive
by Guenther Meyer
::
Rate this Message:
Am Dienstag 23 September 2008 schrieb Jan-Benedict Glaw:
> > that's right. > > but it's not a good solution to use a fixed projection. who knows how > > often they will change it? > > Nobody, unfortunately. > > > so the best way is to read the projection from the database, if possible, > > or to store it somewhere on database creation. > > A quick look at the osm2pgsql code tells me that this isn't stored > anywhere, but I may be wrong. Though, it probably would be nice to add > another table with at least the used SRS, or even the whole projection > string. > least to spill it out... _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
|
|
Re: Mapnik Projection used by gpsdrive
by Jan-Benedict Glaw
::
Rate this Message:
On Thu, 2008-09-25 10:01:25 +0200, Guenther Meyer <d.s.e@...> wrote:
> Am Dienstag 23 September 2008 schrieb Jan-Benedict Glaw: > > > that's right. > > > but it's not a good solution to use a fixed projection. who knows how > > > often they will change it? > > > > Nobody, unfortunately. > > > > > so the best way is to read the projection from the database, if possible, > > > or to store it somewhere on database creation. > > > > A quick look at the osm2pgsql code tells me that this isn't stored > > anywhere, but I may be wrong. Though, it probably would be nice to add > > another table with at least the used SRS, or even the whole projection > > string. > > shouldn't have postgis facilities to store this? > if osm2pgsql knows the projection, it could be made to save it there, or at > least to spill it out... All spatial columns are usually described in the `geometry_columns' table, which contains the `srid', pointing to spatial_ref_sys.srid . That row, in turn, contains the `proj4text' column, which contains exactly what we want: the Proj4 string. Unfortunately, the "Spherical Mercator" projection we use these days aren't already prepared in the `spatial_ref_sys' table. However, at least the SVN version of `osm2pgsql' contains the needed SQL statement (in file `900913.sql'), which, however, cannot be executed by a regular user if the GIS-enabled database was created as recommended by Debian's README (shipped with the postgresql-8.3-postgis package) due to missing INSERT privileges. So I guess we'd simply work on (submit, ask again, ...) the PostGIS people to simply include this SRS, too. That way, a simple SELECT would give us the correct Proj4 string. (However, if somebody *really* changes it, some assumptions will break. Eg. I still wonder about the 0.00028 factor all the time...) MfG, JBG -- Jan-Benedict Glaw jbglaw@... +49-172-7608481 Signature of: Friends are relatives you make for yourself. the second : _______________________________________________ GPSdrive mailing list GPSdrive@... http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive |
signature.asc (196 bytes) 
| Free Forum Powered by Nabble | Forum Help |
