Proposal talk:Area:highway/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

Similarities with waterway=riverbank?

Resolved: --Flaimo 09:40, 10 May 2011 (BST)

You may wish to draw some analogies with waterway=riverbank too, since direction matters for rivers, and rivers need both schematics and areas too. That too uses a different key for the outline, and the suggestions for how to split and how to draw may be applicable to highways too. --achadwick 19:39, 9 May 2011 (BST)

added it. --Flaimo 09:40, 10 May 2011 (BST)

Wrong way to do it

I'm not going to say that "we should never map roads as areas". OSM mapping tends towards completeness and it's probably inevitable that some roads, at least, will be mapped as areas in time.

However, this particular proposal is the wrong idea at the wrong time.

We are already talking about having a dedicated area datatype in API 0.7. This may well provide a native replacement for the current multipolygon relations, among other things (after all, relations are meant for metadata, not geometry; using relations for multipolygons is an ugly hack).

If you would like to see the option for roads to be mapped as areas, you should join the conversation about area types in API 0.7. Post your ideas and concerns to the dev@openstreetmap.org mailing list. The result will be much better in the long term. Please don't try and graft a whole new scheme onto a data model that was never designed for it.

Maybe you're not a developer and feel nervous about proposing ideas like this. That's fine. Those of us who are developers welcome ideas, if submitted humbly rather than in an "you shall do this" fashion.

But as a developer who will probably have to implement part of this (in Potlatch 2) if it ever catches on, I would far rather it was done in a future-proofed manner consistent with the development of the API and data model, than as a kludge on the existing system.

--Richard 20:57, 19 May 2011 (BST)

Can you clarify your concerns? While I see the shortcomings of the present model for representing areas, I fail to see how this has any implications for the proposed tag. This tag is not using areas in any unique way, and in fact by it's very nature data tagged in this manner will have a clear transition path if/when an area object is added to the API model (because there's no ambiguity about whether a closed way is an area or line, like with some other tags). From what you appear to be advocating, we should stop mapping all lakes, buildings, and any other object as areas using the current way or relation (multipolygon) methods. Of course I know you aren't doing that, so I'd ask you to explain what you really mean. -- Joshdoe 03:51, 20 May 2011 (BST)

TMI

"Too much information". While lovely in certain cases, it makes it harder to render pleasing maps when less detail is not on needed but better. Brycenesbitt

Considering that the areas would be mapped in addition to the ways and that a renderer would need to explicitly add support for the areas for them to appear at all, I don't see how they could be an obstacle when rendering maps with less detail. --Tordanik 23:38, 3 September 2011 (BST)