highway=* with area=yes are already most often for highway=pedestrian, but
actually renderers already apply consistant representations whe nthese are
used  for other types of highways: the typical use is the representation of
residential highways without exit: instead of a terminal node with a single
highway=turning-circle (which is not very accurate as in most cases the
shapes are pentagonal), the highway is terminated by a  closed
polygon with "highway=residential" + "area=yes".

For now this has no impact on routability there because it is already a
no-exit. But areas still cause problems for routers: for such case we need
to have BOTH a linear representation and the area representation (already
used for plazzas, which also typically have their own name, independantly
of the highway name that crosses it and represented by the linear
representation keeping the name of the street, notably to keep continuity
in addresses with house numbers).

Slowly however, routers and address finders are able to consider areas ;
and note that in some countries or cities (notably in Eastern Asia), house
numbering is made by blocks: blocks are named and represented by surfaces
enclosing several highways, and housenumbers are grouped in that block
independantly of the highway passing through the area.

We are almost ready to have support for both representations (justs like
what was made for rivers with the oriented linear waterway=* and and
non-oriented area-based riverbanks, all of them beoinf groupable in a
relation for the whole river): what is missing is some support in routers
(to determine ways to go): note that we still need the linear
representation at least for one central lane to allow tagging directions
(not possible for tagging restrictions correctly: an area has no well
defined direction even if its shape is a long rubber. using the two
abstractions gives the best of both world and allows compatibilyt with
existing routers which most often ignore areas, and that's why areas are
used most often only for pedestrian areas and no-exit).

However a good question is how to delimit the shape of these streets: only
the areas where vehicle are driving, or including the side parkings, or
including also the footways. detailing of areas by lane seems excessive. In
my opinion, the shape should include the whole street: including parkings
and footways, and separating kerbs or plantations which can be drawn inside
them, but excluding the private areas: it should be limid to barriers,
gates, walls and should not touch the buildings.

Another difficulty existes for bridges: bridges are already representable
(and represented) as shapes with building=bridge, which is convenient to
avoid splitting bridges in two parts when there's a physical central
separation built on top of the bridge. This really helps improving the
rendering of bridges as a single structure, even if on top of it there are
separated unidiretional highways, cycleways, footways, or railways/subway
lines. And note that some bridges also exist on top of buildings and can
pass in the middle of them in a tunnel ! The linear representation only is
difficult to render and interpret on the map but remains useful for routing
algorithms and directional restrictions (and also allows orienting
correctly the labels of street names).

A standard rendering will draw linear highways on top of area-based
highways, making them invisible if the fill colors are identical, provided
that shapes used to render the linear highway do not use any thin borders
to constrast them with the background, but some borders are still drawn
when there steep inclines or protecting walls: these walls should then not
be tagged on the linear highway in that case, but separately on the OSM
ways defining the highway area: this could require using areas represented
by multipolygons, and many people with have difficulties working with them,
so area-based highways will be introduced very slowly, and only in
relatively stable areas which are already densely mapped, to improve the
rendering for high zoom levels and allow easier interpretation. In most
cases, area-based highways are not needed (notably in rural areas, or for
tracks, or for most roads in developping countries where the areas are
unstable across seasons and fuzzily-delimited, and there's actually no need
to represent data with high density of details such as street lights,
signals, bus stop areas, parking lots, recycling containers, details of
footways and crossings, including accessiblity tags for equipments for
walk/vision-handicaped people, and other public equipements on footways
such as benches, water fountains, information panels, and advertizing
panels).

I don't think that OSM should forbid the area representation, but it should
be only a secondary goal, after completing the linear and
oriented representation.


Le ven. 10 août 2018 à 14:22, Jérôme Seigneuret <jerome.seigneu...@gmail.com>
a écrit :

> @djakk all object are area but that don't make sens use it in database
> because data are an abstraction.
>
> area is documented!
>
> highway are in model linestring but in other context it is as an area so
> highway area are forced with area=yes to map this object. there is no other
> solution to set an highway as a linstring because you can't easily have a
> good reprensentation with low level scale and can't map name correctly.
> But for micro mapping and set more realistic area (use in zoom level 19,
> 20 for representation) and data analyse there is an other model and you can
> join twice solution. It can be similar to interlis (suisse model)
> reprensetion based on data abstraction multilevel. Same data have multiple
> object type representation of your information with level scale definition.
>
> database is just a container and store an abstraction of information with
> a specific model. You can translate with same model or an other but there
> is a limitation corresponding to you abstraction level. an highway is also
> a 3D reprensation with concrete layers, kerb, and sidewalk...
>
> In other way you separete highway, cycleway, footway and other is there is
> a separator but this is the same global 3D object but you need use vector
> line and contrains for routing and it can use just in global polygon
> object. in this base you need use polygon and line solution.
>
> Other limitation is time cycle, number of contributors, resource
> materials.... and you will do choices to add udpated data in time.
>
> Jerome
>
> Le ven. 10 août 2018 à 13:23, djakk djakk <djakk.dj...@gmail.com> a
> écrit :
>
>> No, all highways are areas :) Mapping them as a line is a manual
>> generalization ;)
>>
>>
>> djakk
>>
>>
>> Le ven. 10 août 2018 à 12:15, Andy Townsend <ajt1...@gmail.com> a écrit :
>>
>>>
>>> > So basing on your opinions, it looks like highway=* + area=yes isn't
>>> incorrect, it's just not documented.
>>>
>>> I'd suggest that it depends what you're mapping. If it's a predominantly
>>> linear feature then it would be wrong to try and "somehow record the width"
>>> using area=yes on the highway tag - use area:highway (or width) for that.
>>>
>>> If it really is an area, then area=yes would make sense.  Most highways
>>> are not, though.
>>>
>>> Best Regards,
>>> Andy
>>>
>>>
>>> _______________________________________________
>> talk mailing list
>> t...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à