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
