Re: [OSM-dev] osm2pgsql: support for local route names
RainerU-2 wrote
Hello Kai,
Am 14.04.2013 21:47, schrieb Kai Krueger:
Perhaps I don't quite understand what you need, but does osm2pgsql not
already do this?
osm2psql creates a way entry in the planet_osm_line table for each member
of a
route relation. The name tag of the relation is copied as route_name from
planet_osm_rels to each of these ways, along with some other tags specific
for
hiking and cycling routes. This allows to render routes with simple query
statements.
If I am not mistaken, it tries to create one entry per relation. However, as
in its default mode, osm2pgsql does not create multi-geometries, there will
be one entry per contiguous geometry in the planet_osm_lines table. It is
not per member way. If you have hstore enabled, these entries obtain all of
the tags, including e.g. name:fr from the relation they represent. For route
relations, they do not contain any information other than the geometry from
the member ways.
In addition the individual member ways are also in the planet_osm_line
table, but those do not contain any tags from the relation.
One problem you might be facing is that osm2pgsql does not handle relations
of relations, or relations of relations of relations... It seem many of e.g.
the Swiss cycle network is constructed of relations of relations and the
international names seem to be on the outer most relations. Therefore the
correct taging is only applied to the geometry sections of ways that are
directly a member of the parent relation.
RainerU-2 wrote
With the hstore option (which I was not aware of before Shaun mentioned
it) all
the tags of the relation are stored in planet_osm_rels but not in the
derived
ways in planet_osm_line.
No, the hstore option does not have an effect on the planet_osm_rels table.
The planet_osm_rels tables has all of the tags of the relations, wether you
select hstore or not. However, those do not contain any postgis geometries
and are therefore not easily used directly in rendering. The hstore option
influences the rendering tables, i.e. planet_osm_{point|line|roads|polygons}
and can be used directly in rendering with the apropriate options in mapnik.
RainerU-2 wrote
To access these tags one had to build a query that goes
through the member column values of the relations and gets the associated
ways.
This is a bit too complex for non-database geeks like me.
One solution would be to add the osm_id of the relation to the derived
ways.
This would provide a not too complex way to query these ways along with
data
from the associated relation. This is easy to implement, in the same way I
did
for the name:xx tags.
All of the entries in the rendering tables are linked back to a osm feature
with the osm_id. If they were derived from a relation, then the osm_id is
negative.
Kai
--
View this message in context:
http://gis.19327.n5.nabble.com/osm2pgsql-support-for-local-route-names-tp5756704p5757124.html
Sent from the Developer Discussion mailing list archive at Nabble.com.
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
Kai Krueger kakrue...@gmail.com wrote: So name:de and name:fr are already available in the standard osm2pgsql db. Also all other tags of the route relation are in the db. Why osm2pgsql translates the name tag into route_name, I don't know. Also I wonder why there is so much special casing of various ncn, rcn, lcn cycle relations? All this stuff predates hstore support. Sven -- Dynamische IP-Nummern sind Security-Homöopathie. (Kristian Köhntopp) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
Am 15.04.2013 09:04, schrieb Kai Krueger: If I am not mistaken, it tries to create one entry per relation. However, as in its default mode, osm2pgsql does not create multi-geometries, there will be one entry per contiguous geometry in the planet_osm_lines table. It is not per member way. If you have hstore enabled, these entries obtain all of the tags, including e.g. name:fr from the relation they represent. For route relations, they do not contain any information other than the geometry from the member ways. That is how it works. As I said, I just discovered hstore support. Consider the proposal from the OP as obsolete. Rainer ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
Am 13.04.2013 11:34, schrieb Shaun McDonald: Another option is to use the hstore options of Postgres and osm2pgsql and form the queries based on that. Doing it that was will probably use less diskspace and avoid having too many columns etc. Currently hstore has no effect on ways created from route relations. So you mean, I should extend hstore processing in osm2pgsql to these ways? Rainer ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
RainerU-2 wrote Hello, For map rendering I needed the local names of route relations such as name:de, name:fr. As osm2pgsql does only copy the name tag from the relation to the related ways, I modified the program to copy all the name:xx tags to route_name:xx on the ways. Perhaps I don't quite understand what you need, but does osm2pgsql not already do this? As an example I looked at relation 8497 ( http://www.openstreetmap.org/browse/relation/8497 ) which is a bicycle route through Liechtenstein and has internationalised names. It has the following tags: tag k=name v=ncn 2 - Rhein-Route (Andermatt–Basel)/ tag k=name:de v=ncn 2 - Rhein-Route (Andermatt–Basel)/ tag k=name:fr v=ncn 2 - Route du Rhin (Andermatt–Basel)/ tag k=network v=ncn/ tag k=operator v=Veloland Schweiz/ tag k=ref v=2/ tag k=route v=bicycle/ tag k=type v=route/ In the osm2pgsql database with hstore enabled, there is an entry for this relation in the planet_osm_line table, this has the following hstore value for tags: ncn=yes, ref=2, route=bicycle, name:de=ncn 2 - Rhein-Route (Andermatt–Basel), name:fr=ncn 2 - Route du Rhin (Andermatt–Basel), ncn_ref=2, network=ncn, operator=Veloland Schwe iz, route_name=ncn 2 - Rhein-Route (Andermatt–Basel), route_pref_color=0 So name:de and name:fr are already available in the standard osm2pgsql db. Also all other tags of the route relation are in the db. Why osm2pgsql translates the name tag into route_name, I don't know. Also I wonder why there is so much special casing of various ncn, rcn, lcn cycle relations? What do you gain with your patch? Can you give an example of how you want to use the data? Kai -- View this message in context: http://gis.19327.n5.nabble.com/osm2pgsql-support-for-local-route-names-tp5756704p5757094.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
Hello Kai, Am 14.04.2013 21:47, schrieb Kai Krueger: Perhaps I don't quite understand what you need, but does osm2pgsql not already do this? osm2psql creates a way entry in the planet_osm_line table for each member of a route relation. The name tag of the relation is copied as route_name from planet_osm_rels to each of these ways, along with some other tags specific for hiking and cycling routes. This allows to render routes with simple query statements. With the hstore option (which I was not aware of before Shaun mentioned it) all the tags of the relation are stored in planet_osm_rels but not in the derived ways in planet_osm_line. To access these tags one had to build a query that goes through the member column values of the relations and gets the associated ways. This is a bit too complex for non-database geeks like me. One solution would be to add the osm_id of the relation to the derived ways. This would provide a not too complex way to query these ways along with data from the associated relation. This is easy to implement, in the same way I did for the name:xx tags. Another solution would be to have the tag value of the relation copied to all the derived ways when the hstore option is selected. I would prefer this solution but, as I wrote in my answer to Shaun, I am not able to implement it. Rainer ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
Hi Sven, Am 12.04.2013 12:05, schrieb Sven Geggus: Wouldnt it make more sense to copy all tags probably prefixing route_ to be compatible to the existing code? That's a good point. I will try to implement it like that. Rainer ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
Am 11.04.2013 19:57, schrieb RainerU: As I am not familiar with github, I would need some hints how to proceed. The usual approach would be fo fork the osm2pgsql repo, create a feature-branch, check out that branch, change your code inside, test, commit and push the new branch to your fork of the repo. Then you can issue a pull-request from your branch to the main-master. It may sound a little scary when written down, but it is a relativly straightforward process, once you know the steps involved. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: support for local route names
RainerU ra...@sfr.fr wrote: As it works fine and the risk of regression or side effects seems very low to me, I propose to include this feature into the repository. Do the maintainers of osm2pgsql agree? Wouldnt it make more sense to copy all tags probably prefixing route_ to be compatible to the existing code? Sven -- Dynamische IP-Nummern sind Security-Homöopathie. (Kristian Köhntopp) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
