Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

osm2pgsql exports name for type=route relations #1703

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 1 comment
Closed

osm2pgsql exports name for type=route relations #1703

openstreetmap-trac opened this issue Jul 23, 2021 · 1 comment

Comments

@openstreetmap-trac
Copy link

Reporter: ldp
[Submitted to the original trac issue database at 3.54pm, Thursday, 9th April 2009]

When osm2pgsql is exporting a route to postgis, a route_name key is added, as a copy of the name field of the input relation. However, before it starts to evaluate the different types of relations, the source tags including 'name' are already copied. This causes both the 'name' and 'route_name' fields to be set and identical, for type=route relations.

Because the current osm.xml uses an while rendering road names, this causes the route names to also appear on the map when route_name and bicycle routes are enabled in default.style. Checking [route_name] as an exclusion for road name rendering instead of using an ElseFilter is also not possible, since by default, the route_name column isn't enabled in default.style, the column is not generated, and the whole Rule would fail to render.

Example of route name rendering: http://tile.openstreetmap.nl/?zoom=15&lat=51.22925&lon=3.7797&layers=B000000F

I have added a patch for output-pgsql.c that defers setting the 'name' column in the exported relation, then skipping this for type=route, and finally setting it for the other type=* relations. I tested this locally, and the route names were no longer rendered on the osm.xml based map.

Heads up opencyclemap maintainers: If you're relying on [name] for type=route bicyle routes, this would break label rendering, until you switch to [route_name].

@openstreetmap-trac
Copy link
Author

Author: jburgess777[at]googlemail.com
[Added to the original trac issue at 11.02pm, Tuesday, 19th May 2009]

I put in a fix for this in r15119. I did it slightly differently to your patch but the result should be the same.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant