[Tagging] Mismatched Level of Detail in highways vs. other elements

Dave Sutter sutter at intransix.com
Mon Apr 8 15:51:38 UTC 2013


I like the idea of increasing the level of detail of the streets, and
I agree that this would best be done by separating the routing network
from the visual presentation. I think this can, however, be done in
the existing data model, which is very flexible.

Further, we wouldn't need to disrupt the existing data or the
renderers since the existing data is the routing network. We would
just be adding presentation data, which could be used or ignored.

What would be needed is some modifications in the editors (or at least
JOSM, which I have more experience with), which discourage overlapping
ways. And it would be helpful if the editor did some abstraction to
help users cope with the more complex road structure.

Dave

On Sun, Apr 7, 2013 at 1:35 PM, Martin Atkins <mart at degeneration.co.uk> wrote:
> On 04/07/2013 11:58 AM, LM_1 wrote:
>>
>> In my view the streets should be more detailed - after all having the
>> details dropped by computers is possible (even if not always easy). but
>> detail that is not there cannot be add in any simple way. This case
>> might depending on the precise conditions fulfil the requirements for
>> separate direction lanes. If not some more detailed scheme would have to
>> be used - mapping streets as areas. Eventually that will be the only
>> viable option city centres currently mapped in high detail with only the
>> streets being overly simplified...
>>
>
> I wonder if the root problem is that we've conflated the idea of the
> physical construct of a street with its parallel in the routing network.
>
> The most complete mapping scheme would use areas to describe the physical
> area occupied by the sidewalks, street areas, boarding islands and other
> street features, and then represent the routing network as a separate
> schematic of ways on top of it with little or no visible impact on normal
> rendering. That would be very time-consuming to maintain, of course, and
> would essentially turn OpenStreetMap into a huge, collaboratively edited
> aerial "photograph" with a routing database alongside it. :)
>
> It seems like the current OSM data model is really designed for and best to
> suited the low-detail schematic mapping rather than high-detail mapping;
> abutting features just manifest as ways that happen to share nodes, or
> worse: ways that happen to just sit alongside one another and have to be
> maintained individually by mappers.
>
> An interesting thought experiment is what OSM might look like if it had
> started with a different spatial data model. For example, what if it were a
> graph of connected 2D polygons, like the map format of the Doom or Duke
> Nukem 3D game engine, or even subdividing 3D space with planes like the
> Quake game engine? That sort of model would favor realistic physical mapping
> over schematic mapping.
>
> I wonder if it's really feasible for the use-case of highly-detailed
> renderings and the use-case of highly-accessible collaborative editing of a
> basic highway network to coexist in the same system; the former is something
> that requires extensive effort of a single person or coordinated group,
> while the latter is more suitable when you have many uncoordinated people
> who each have comparatively little time to spend.
>
> (If Google's self-driving cars ever take off in the mainstream I guess we'll
> *all* have the hardware necessary to create an accurate 3D model of the
> world and we'll just have to figure out how to store it!)
>
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging



More information about the Tagging mailing list