Re: [Tagging] wall and block that aren't a barrier

The main idea that i got for barrier=retaining_wall is to indicate that between the lower ground and the upper ground, there is a retaining wall preventing the movement to got this way (most probably, car or bicycle can't go through the retaining wall easily, as it act like a small "cliff").

Re: [Tagging] The endless debate about "landcover" as a top-level tag

> > Seriously, so much time wasted on discussing landuse=forestry and it has > 9[sic!] uses. > I don't see the main argument as good. Any new tag is by definition not used that much ! And most new mappers follow litteraly the rules of "we should use the accepted tags in wiki...". But whatever,

Re: [Tagging] Access=no for bus lanes

Yes the idea behind access=* is a general tag - it indicate for every other transport types (except if another more specific tag is used) : so access=private just say that for every type of transport it is a private access, and if you add foot=yes, it became "private for everyone except people on

Re: [Tagging] Feature Proposal - RFC - Telecom local netwoks

In Belgium, we often call them "Local EXchange (LEX)", that's a simple name change from the "telephone exchange" that at least indicate that it is not only telephone in it ! The name vary but it always refer to the same "central office or telephone exchange" and the difference is probably only

Re: [Tagging] Lane geometry in OSM

If you look at the wiki page about different lanes tagging ( https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a suggested w 2018-08-02 23:56 GMT+02:00 Tom Hardy : > I've experimented a bit with lane and road attributes as in > https://www.openstreetmap.org/way/505256201 and the

Re: [Tagging] Lane geometry in OSM

the width tagging for transition lane (where one lane split to two (or conversely). There are already a lot of possibility to tag detailed lanes, but we could indeed add the width in it ! PS: sorry for the previous message, i miss-clicked. 2018-08-03 13:08 GMT+02:00 Lionel Giard : >

Re: [Tagging] Lane geometry in OSM

> Also, I often see a center lane for left turns in both directions, as in > https://ecn.t0.tiles.virtualearth.net/tiles/a0213330110033323031.jpeg?g= 6570 > That's next on my list. It's currently tagged as a two lane road just a > bit west of the intersection I referred to earlier. Note the

Re: [Tagging] undersea tourist route

I also agree with the location tag as it say it is underwater, while the other method say that the path is made of "water" (as it would be made of gravel or asphalt in other places). Note that the tag layer=-1 don't mean anything by itself (if there is no other data at the same location) as it is

Re: [Tagging] Tagging suggestions for electricity

I'm also thinking that power_supply is different, as it give only information of the type of power plug available in a location ! Implicitly it would probably mean there is electricity there but for private houses, we can't know that information without entering houses, and it doesn't say if they

Re: [Tagging] landuse=basin

I would also add that "water=reservoir" is a sub-tag of "natural=water"; while "landuse=reservoir" is a tag that can go alone by itself. The main thing is that the second scheme is older than the first, and thus still more used. Looking at the proposal to "simplify water tagging" that was approved

Re: [Tagging] Designated value as a key

I'm not seeing much difference seeing "designated=bicycle" versus the in-use combinaison "bicycle=designated" (same for the other common tag like motor_vehicle) except that the first one would use a different "access paradigm" than everything else. That's not really a simplification to me, and i

Re: [Tagging] mast / tower / communication_tower (again)

Looking at the definition on the wikiproject telecom https://wiki.openstreetmap.org/wiki/WikiProject_Telecoms (in the part "Antennas / Masts / Towers", there is a section to indicate how to tag the mast, tower ...: >From my understandings, the three (four) cases are currently : - a vertical

Re: [Tagging] issues with the list of deprecated features

> > I am not sure how it changes that we ended with tourism-artwork as a >> standard. >> >> Also, "has nothing at all" is not true. Artworks are quite likely to be a >> tourism attractions. >> >> > > > following this argument, we would have to tag the national parliaments as > tourism=parliament

Re: [Tagging] historic=memorial tagging question.

I would use memorial=stele (as it looks like a stele to me). If you go on wikipedia it looks like some of the "usual" stele : https://en.wikipedia.org/wiki/Stele . Le mer. 17 oct. 2018 à 11:22, John Willis a écrit : > How would I map this object? >

Re: [Tagging] mast / tower / communication_tower (again)

Maybe we should inspire us from the power=* scheme and using a telecom tagging like (i'm looking to the idea of "power=pole" compared to power=tower) : - Keeping the tagging as a man_made=tower (or other suitable tag) for big tower (like Eiffel tower) that have other purpose, and only tag the

Re: [Tagging] mast / tower / communication_tower (again)

At my work (a telecom company in Belgium), i see these types of mobile structure construction : - *Self-supported pylons* (the "*tower*", mostly looking like the power=tower in OSM, but also including the (older) self-supported tower in concrete) ; - *Guy-wired pylons* (the "*mast*" as described

Re: [Tagging] Estimated values for height

You can also use height=* for both and add a "souce:height=estimated / measured" tag with that to have a value that is usable by the apps and tools but still keeping the information that it was only estimated ! ;-) Lionel Le ven. 9 nov. 2018 à 10:19, Dave Swarthout a écrit : > There is

Re: [Tagging] mast / tower / communication_tower (again)

I also support this simplification of definition and tags. Is there a possibility to indicate that a tower is specifically a landmark with a tag of some sort without knowing the height (most of them are not publicly known around here) ? Because some are really useful for navigation (visible from

Re: [Tagging] mast / tower / communication_tower (again)

The problem i see with that "multipurpose" value is that it give no information and could be misused for other tower:type (like defensive;observation) which should not be rendered as communication_tower. Thus i would propose to render the "communication_tower" based on the height > 250 m

Re: [Tagging] Feature Proposal - RFC - Telecom local networks

In this proposal we use "telecom" key, but i would like to know what is the limit/definition of this key ? Does it englobe internet provider, tv provider and mobile provider (even if the company does only one of them which is rarer today) ? Or only some of those ? My question come from the wiki

Re: [Tagging] relation site <> multipolygon

My main use for site relation are for historical sites to group the historical elements of the castle or other historical site including the wall, moat, buildings (especially the ones touching each other) and various nodes. An example in the historical commandry of the Hospital order (in Belgium)

Re: [Tagging] Area of Firestations / Area of Ambulancestations

It depends as some ambulance_station are located inside the hospital campus, some other are "external services" and are only a sort of "depot" like for taxi or buses. Personaly, I don't think landuse is a good tag for that. Why not an amenity tag like everything else ? (amenity=ambulance_station

Re: [Tagging] [OSM-talk-be] cadastral plan now open data

André, i don't really see your point with the argument you made about cadastre data. i don't know of anybody looking to use this data to add building into OSM. It is outdated data regarding buildings and roads in a lot of different place in Belgium. And as, the people at cadastre are not the

Re: [Tagging] The actual use of the level tag

Yes it makes sense to keep this distinction : level tag can just be the "logical order" of levels going from -xx to xx with an arbitrary 0 for each building, so tools know the order (which one is above the other). Simple Indoor Tagging already suggest the level:ref for the "local" naming scheme.

Re: [Tagging] The actual use of the level tag

As pointed out for underground station, the building outline doesn't always cover the underground levels (i.e. the underground levels can extend far beyond the building limit (and potentially under other buildings/roads...). We find this problem for metro station, train station or other buildings

Re: [Tagging] Fwd: Re: Forest parcel with other landcover (scrub, scree…): how to map?

To summarize the different points of the recent messages, there are 2 points concerning the tag changes described as an alternative to landuse=forest or natural=wood : 1) *Landcover :* - landcover=trees -> for areas with trees (instead of *landuse=forest* or *natural=wood*); -

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

*@OSMDoudou :* At the moment, i only used the role entrance for the underground parking site relation with some parking_entrance, because it was suggested by JOSM. Roles could be used when the situation is complicated (ex : no clear perimeter exist -> like for underground parking), it may then be

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

You are right in that in regards to KISS, i was not seeing it as being more complex but easier to interact with the parking_space elements via editor (but that was personal preference for sure). I was also following the description here https://wiki.openstreetmap.org/wiki/Proposed_features/parking

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

In my use of the site relation, i try to add a polygon to indicate the perimeter (when possible) like in the proposal of the site relation ( https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site) and i use the "amenity=parking" polygon for the site=parking. And then i add everything that is

Re: [Tagging] shop=plumber vs shop=plumbing vs shop=plumbing_supplies

Keep in mind that there is already the tags "man_made=works" + "products=*" for industrial scale production. Like the example of a brewery that can be tagged as craft=brewery (when small) or via man_made=works + product=beer (when industrial). To my understanding, at trade shop can't really be

Re: [Tagging] shop=underwear vs shop=clothes + clothes=underwear

I think that the shop=underwear could be deprecated indeed, as the other tag is similar and more used (and probably more practical as it is a sub-category of clothes shops). For the underwear or lingerie name, both value are existing for "*clothes=**" (depending if only selling for women or

Re: [Tagging] Feature Proposal - RFC - police=*

That's why the proposal state that we will keep the amenity=police tag on the public-facing object so that they will still be backward compatible at the moment. Thus, the "technical" problem doesn't exist, and if we drop the amenity tag in the end, it will be probably after (at least) a year - if

Re: [Tagging] Feature Proposal - RFC - police=*

I don't see why people would care that much about a tag that could be seen as a sub-tag at first (look at all the chain of tag that we have like : man_made=street_cabinet + street_cabinet=power + power=substation + substation=minor_distribution). So someone don't like the "amenity=police" +

Re: [Tagging] Subtag for place=locality?

In Belgium (where i map), we generally use this tag for place without population that have a name ("lieu-dit" in french (look at this wikipedia article) ), like a crossroads (like "Carrefour de la Justice" (literally "crossroads of justice")), a field, a

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

The editor presets are already changed (so any modification or new creation of embassy, consulate or liaison use the new tagging scheme). The number of diplomatic=* tag compared to the number of office=* tag is due to the fact that the "diplomatic"=* tag was already existing but used slightly

Re: [Tagging] Ho to tag the position of objects on highways

For things like manhole or poles, i just tag them at their real position, as it is not useful to connect them to the highway line which exist mostly for routing purpose. There are a lot of object that can exist on the area of a road (a pole, a manhole, a barrier, an underground fire hydrant,...)

Re: [Tagging] Wiki changes for police tag

I also see it as a top-level tag. i find it similar to the recent "healthcare=*" which can be used by itself too. Le sam. 18 mai 2019 à 11:46, Jan S a écrit : > Interesting point... I'd suggest that it is a top-level tag itself. > Otherwise you'd have to tag buildings as building=* and

Re: [Tagging] Feature Proposal - Voting results - Police facilites

There isn't any EU police or military force (that's still a political discussion but there is none at the moment). The only existing thing is the international cooperation that is increased between neighboring countries and some special rules allowing one police force to pursue a suspect in the

Re: [Tagging] Charging stations: socket::output -- which format for the value?

All electric charging station that i have ever encounter are in "kW" not in watt (ex: 3 kW, 50 kW, 120 kW, 175 kW...). To me, it is the same as the maxspeed tag, we don't put it in m/h but in km/h -> we use the common unit as everyone use it. Thus we don't use the SI value everywhere and that seem

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

I think that the only deprecated tag in the accepted proposal is "amenity=embassy" (which is indicated on the wiki page too). The wrong diplomatic value are just what old tagging scheme lead to. It doesn't need to be deprecated to me as it never existed officially (i think) - and it will probably

Re: [Tagging] How to tag Seveso sites ?

Seveso sites are all sites identified as source for a "potential major industrial hazard" (mainly big chemical plant - and it doesn't include the military or nuclear facilities). It is named after the Seveso disaster of 1976 (Seveso is a town in

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

If i understood correctly the objective of the revamping of healthcare is to change the old way of tagging all these "amenity" (hospital, clinic, pharmacy, ...) and use the "healthcare" key instead. But at the moment, the preset is using both tags at the same time. So i'm asking the following

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

That's clearer when we get all the history thank you Joseph ! :-) I agree with you that the added value of duplicating the key is very limited, so i understand your edit on the wiki. ^_^ Le mer. 29 janv. 2020 à 14:49, Paul Allen a écrit : > > On Wed, 29 Jan 2020 at 13:34, Joseph Eisenberg >

Re: [Tagging] amenity=faculty?

Site relation are more used to put the tag "amenity=university" and all the information only 1 time for the whole university when it is spread across a city or multiple sites. This site relation equal to the amenity=university area under a campus that's all grouped into one place. Otherwise, if

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

In my usage, i always thought that using a barrier=* + any other main tag was wrong and widely accepted (as i saw that it was separated in most examples when i started mapping). Thus my method has always been to map them separately (one way for the barrier and one way for the other main tag, even

Re: [Tagging] amenity=faculty?

One problem with multipolygon relation is that by definition you can't put *node *it those and you can't put *contiguous buildings* either. How do you group "node + polygons + multipolygon" (some buildings are a multipolygon already where the hole is not part of the university ^_^) with other

Re: [Tagging] amenity=faculty?

The site relation was originally created for groups of features : power plant (wind turbine nodes spread over the land or sea), historical sites (often only some element (one tower, one building, ...) are historic and not the entire place) and parking (especially underground parking with only

Re: [Tagging] amenity=faculty?

Each country (and maybe university) have different subdivision, and sometimes even inside one university there are multiple different subdivision co-existing : for example in Belgium i know at least a few universities that use two separate division at the same time : - for the education part :

Re: [Tagging] distance_from_road tag

Yes this is something you can do with any distance algorithm in available in any GIS tool. That's not something that i would ever map as it would vary with any geometry change of the ways between the road the point you measure, added to the fact that it add nothing to explicitly map it (in my

Re: [Tagging] EV charging stations questions and proposals

For motorcar vs car, it seems logical to update it to motorcar as it is the recommended way of tagging car access, as it is probably just an old wiki information on the amenity=charging_station. At the same time, should we use another tag than scouter=* for them ? Because it is not an existing tag

Re: [Tagging] Question about capacity:*=* on parking_space

Allesandro, I wasn't speaking about disabled only here, even if it must exist countries where disabled are marked but not enforced by law, but i don't know any example. But for other dedicated parking space like "parent" or "electric charging", there are not many country enforcing them by law,

[Tagging] Question about capacity:*=* on parking_space

Hello everyone, I saw that on the parking_space wiki page it says that we shouldn't use capacity:*=* on parking_space, and instead use the access tag. But why is this the case? It seems logical to use capacity:disabled=* on a parking_space for disabled people or capacity:charging=* on a

Re: [Tagging] Question about capacity:*=* on parking_space

disabled people parking spaces : just look for capacity:disabled=* > and you're good to go, whatever it is a parking or parking_space. > > Best regards, > > Adrien P. > > Le 17/01/2020 à 09:36, Lionel Giard a écrit : > > Hello everyone, > > I saw that on the park

Re: [Tagging] Incomplete addresses

In Belgium, the only two mandatory field are "house number" and "street name", postcode and municipality/city can generally be derived from administrative boundaries and thus are optional. I see a lot of people using ID and adding those, as well as the country which is really not needed (because

Re: [Tagging] Refining heritage tag

In my experience of mapping heritage stuff (mainly in Belgium), i never found any case where i would need to re-use the scheme *ref:=* *(where the "" is the group of letter given by the other tag *heritage:operator=*) for another thing (and it was always comprehensible, as all other subtag of the

Re: [Tagging] Please fix unnamed square tagging / was: ... description of place=square

My only problem with "fixing unnamed place=square" is that i know at least 2 locations where the village center open area is definitely a place=square (i.e. an open area with some car parks, and open just in front of the church that was historically the place for gathering people but also cattle

Re: [Tagging] Updating definition and description of place=square

If we take the key "place=*", all the values are only related to toponym : place=city/town/village/neighbourhood/locality/... They all are just the name of a location of some type (either defined by population or other aspect like an ocean/sea/...). So the place=square tag seems to be the only one

Re: [Tagging] site relations for city walls?

The aurelian walls left today are not one continuous element, so the site relation is practical as it allows to group all the linear or area features that are forming the old city walls. I used many time in cities when few ruins of the same original object exist at different places (often walls),

Re: [Tagging] site relations for city walls?

I also saw it used for parking lot that are completely separated (like on two sides of a big highway) but still part of the "same" parking technically (like the example of mall parking in different parts separated by highways). To add to the two area mapped as amenity=parking, there was a site

Re: [Tagging] site relations for city walls?

> > Wouldn't a multipolygon with just two outers solve that parking case? > Best Peter Elderson > That's a bit of a stretch of the multipolygon definition as there is no inner ring. I never used multipolygon for anything else than complex geometry (with inner ring(s)) and that seems to be what

Re: [Tagging] site relations for city walls?

In the parking example that i talk about, the multipolygon is not usable if i want to indicate the specificity of each part of the parking lot like capacity or capacity:disabled (as the tagging is global for every outer part). I like the site relation as it allows to also group the vending machine

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

The idea behind clarifying the amenity=charging_station for a place where there is one or more charge points, is that we use the same idea for amenity=fuel where it just shows the place where there is one or more fuel pump. Also most of the time for charging station in my area, it was already

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

At the moment, the tagging scheme for charging station ask to indicate capacity (for number of charging point) and socket (for the type of socket like CCS or slower charging standard, and the respective number of each) and socket power (ex a ccs charger with 350 kW max power) is also indicated if