Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

public_transport=* not supported #134

Closed
Newbie07 opened this issue Aug 24, 2013 · 8 comments
Closed

public_transport=* not supported #134

Newbie07 opened this issue Aug 24, 2013 · 8 comments
Labels
enhancement new features Requests to render new features

Comments

@Newbie07
Copy link

Please support the public_transport=* tags

public_transport=platform on closed ways is always an area if not area=no is present.

@pnorman
Copy link
Collaborator

pnorman commented Aug 25, 2013

The specific issue you have raised (representing a way as a linestring vs a polygon) is an osm2pgsql issue, not an openstreetmap-carto issue.

@pnorman pnorman closed this as completed Aug 25, 2013
@Newbie07
Copy link
Author

Wait a minute. This issue is about "public_transport=*" in general. Nothing is rendered so far and cause of this the old tagging scheme is still used. I did change several stops to the "new" scheme only to not find them anymore on the map.

See these mapnik tickets which are all valid for carto:

The area problem was only a hint and is not specific for public_transport but to all closed ways which tags do not make sense to be rendered as loop.

@cquest
Copy link

cquest commented Aug 26, 2013

The new tagging scheme is not well designed to be easily used by most rendering.

For example, to render the equivalent of highway=bus_stop, you have to get the public_transport=platform which may not say anything about being a bus stop or railway... so you have to rely on relations which in the usual rendering chain (osm2pgsql > mapnik) are not handled as @pnorman explained.

@pnorman
Copy link
Collaborator

pnorman commented Aug 27, 2013

I think you're better off opening smaller tickets for individual features if you want an alternate tagging supported.

The Public Transport proposal is complex and it's not clear what you want rendered, how you want it rendered, and what is actually renderable.

Keep in mind, openstreetmap-carto is designed to use the standard osm2pgsql chain and it's entirely possible to design a relation scheme that can't be rendered with that.

@Newbie07
Copy link
Author

Ok, for a start, please render "stop_position" like "_way=_stop" and platform like "*way=platform".

I am not talking about relations or stations.

Somehow we need to like the chain of tool together, as it is not that nice to open several tickets on different sites and people will often refrain to do it.

@scaidermern
Copy link

I second the previous comment. These two rendering suggestions are easy to implement and will result in a similar rendering like the old transport tagging scheme. No relations are involved, just two tags.

@AndiG88
Copy link

AndiG88 commented Mar 30, 2014

"For example, to render the equivalent of highway=bus_stop, you have to get the public_transport=platform"

highway=bus_stop is not even clearly defined as public_transport=platform equivalent, it can just as well be used on the way like public_transport=stop_position http://taginfo.openstreetmap.org/tags/public_transport=stop_position#combinations

@pnorman
Copy link
Collaborator

pnorman commented Mar 31, 2014

highway=bus_stop is not even clearly defined as public_transport=platform equivalent

1142673/1295234 (88%) of highway=bus_stop are not part of any way. Of the 12% that are part of a way a reasonable portion of those will be part of a footway, not part of the road. There's a pretty clear standard usage. In any case, this particular issue is closed in favour of more specific issues and also 4 months old.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement new features Requests to render new features
Projects
None yet
Development

No branches or pull requests

5 participants