[Tagging] de facto -Status not working?

It seems that for some reason "de facto" is not recognized as value in the templates any more? Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

Le 16.12.22 à 08:30, Mateusz Konieczny via Tagging a écrit : 16 gru 2022, 02:51 od graemefi...@gmail.com: On Fri, 16 Dec 2022 at 10:59, Andy Townsend mailto:ajt1...@gmail.com>> wrote: doesn't explain why "amenity=lifeboat" is "deprecated".  Like it or not, this is used

Re: [Tagging] Homogenize diplomatic tags

15 gru 2022, 20:55 od ajt1...@gmail.com: > > > Deal? > > > No.  > > > You appeared to have ignored the advice that you were given and gone > ahead and performed a mechanical edit anyway. > > (...) > > However - nothing whatsoever about the others.  You didn't bother to > wait for a

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

16 gru 2022, 02:51 od graemefi...@gmail.com: > > On Fri, 16 Dec 2022 at 10:59, Andy Townsend <> ajt1...@gmail.com> > wrote: > >> doesn't explain why "amenity=lifeboat" is "deprecated".  Like it or >> not, this is used exactly how you'd expect: >> >> >>

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On Fri, 16 Dec 2022 at 12:15, Andy Townsend wrote: > Most of the time, yes they can* - 8000 launches per year between 400 > lifeboats is on average 20 per year. If we take a guess at 8 hours per > launch, it's there 98% of the time. > By those numbers, yep, perfectly correct! But those 8000

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On 16/12/2022 01:51, Graeme Fitzpatrick wrote: On Fri, 16 Dec 2022 at 10:59, Andy Townsend wrote: doesn't explain why "amenity=lifeboat" is "deprecated".  Like it or not, this is used exactly how you'd expect: https://map.atownsend.org.uk/maps/map/map.html#20/54.48811/-0.61310

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On Fri, 16 Dec 2022 at 10:59, Andy Townsend wrote: > doesn't explain why "amenity=lifeboat" is "deprecated". Like it or not, > this is used exactly how you'd expect: > > https://map.atownsend.org.uk/maps/map/map.html#20/54.48811/-0.61310 > But as I've pointed out a couple of times before, by

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On 15/12/2022 23:34, Graeme Fitzpatrick wrote: & it's also a shame that they couldn't have been mentioned as unresolved when I said twice that it was ready to go to voting! I think that any "reading of the room" yesterday (when it was moved to voting) would suggest that the issues raised

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

Voting cancelled to discuss issues. On Thu, 15 Dec 2022 at 23:53, Marc_marc wrote: > > it's a shame to have gone to the vote without resolving the 5 issues raised > & it's also a shame that they couldn't have been mentioned as unresolved when I said twice that it was ready to go to voting!

Re: [Tagging] Homogenize diplomatic tags

> Deal? No. You appeared to have ignored the advice that you were given and gone ahead and performed a mechanical edit anyway. I only spotted it by accident when I noticed that the documented keys that I was using which used to have data in them no longer did: *

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

Le 15.12.22 à 04:25, Graeme Fitzpatrick a écrit : No further comments or discussion so moved to voting: https://wiki.openstreetmap.org/wiki/Proposed_features/emergency%3Dlifeboat_station#Voting it's a

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

No further comments or discussion so moved to voting: https://wiki.openstreetmap.org/wiki/Proposed_features/emergency%3Dlifeboat_station#Voting Thanks Graeme On Mon, 12 Dec 2022 at 12:59, Graeme Fitzpatrick wrote: > I've made a minor change to the format of the possible tags to include. > >

[Tagging] Feature Proposal - RFC - healthcare=department

Mappers, I'm proposing https://wiki.openstreetmap.org/wiki/Proposed_features/healthcare%3Ddepartment A tag for mapping departments of hospitals or clinics. We can discuss it here on the mailing list, but there is already an active discussion on the community web site:

Re: [Tagging] building=entrance

I also support that mass retagging of building=entrance nodes attached to buildings. -- Andrew From: Martin Koppenhoefer Sent: 13 December 2022 00:26 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] building=entrance sent from a phone >

Re: [Tagging] building=entrance

sent from a phone > On 12 Dec 2022, at 22:13, Marc_marc wrote: > > i dislike the idea to have tag with several meaning depending > if it's on a node or a closed way One could say the distinction is in the meaning, not in the object type, there is a tag that was used in the past on nodes

Re: [Tagging] building=entrance

Le 12.12.22 à 20:27, Martin Koppenhoefer a écrit : Following a JOSM discussion I wanted to ask here, if someone else is using building=entrance to tag entrance buildings. it doesn't look like to be a building but a indoor=* (root ? entrance ?) and sometime a building:part (for 3D tag) i

Re: [Tagging] building=entrance

On Mon, Dec 12, 2022 at 3:51 PM Jmapb wrote: > On 12/12/2022 2:28 PM, Martin Koppenhoefer wrote: > > Following a JOSM discussion I wanted to ask here, if someone else is > > using building=entrance to tag entrance buildings. > > > > It is a term that seems well introduced and understandable, so

Re: [Tagging] building=entrance

On 12/12/2022 2:28 PM, Martin Koppenhoefer wrote: Following a JOSM discussion I wanted to ask here, if someone else is using building=entrance to tag entrance buildings. It is a term that seems well introduced and understandable, so there is not much hindering people from using it, just that

Re: [Tagging] scope of emergency=dry_riser_inlet

The only problem I see with many top-level tags is editors would need to make 4 very similar presets, which is pretty confusing and forces mappers to pick one option, even if they don't understand the difference... ___ Tagging mailing list

Re: [Tagging] building=entrance

sorry, missed the link https://josm.openstreetmap.de/ticket/22570 any comments on the tag? Someone else using it for buildings? Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] building=entrance

Following a JOSM discussion I wanted to ask here, if someone else is using building=entrance to tag entrance buildings. It is a term that seems well introduced and understandable, so there is not much hindering people from using it, just that there was the bad practice to use the same tag on

Re: [Tagging] Relations of type=site + tourism=camp_site

On 11/11/22 23:25, Casper Kersten wrote: Site relations are usually completely redundant if you just tag an operator=* tag. A tourism=camp_site closed way or multipolygon is, of course, a camp site, and a shop or parking area on or belonging to that camp site should get an operator=* tag with

Re: [Tagging] Relations of type=site + tourism=camp_site

On 10/11/22 22:36, Martin Koppenhoefer wrote: sent from a phone On 10 Nov 2022, at 12:31, Yves via Tagging wrote: Site relations are often used to models thing that aren't spatially joined, like windfarms, universities... I can easily imagine it's reasonable to use them for campings in

Re: [Tagging] scope of emergency=dry_riser_inlet

Am So., 11. Dez. 2022 um 04:25 Uhr schrieb Kyle Hensel < k.y@outlook.co.nz>: > I think we need a new tag then. In New Zealand dry risers are not allowed > for new buildings, since charged systems are safer... > > > > François’s suggestion of emergency=riser_inlet + a sub tag seems like a >

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

I've made a minor change to the format of the possible tags to include. If there are no more comments, I'll move to voting in the next day or two. Thanks Graeme On Thu, 8 Dec 2022 at 00:33, Marc_marc wrote: > Le 07.12.22 à 07:31, Warin a écrit : > > > > On 7/12/22 01:54, Marc_marc wrote: >

Re: [Tagging] Feature Proposal - RFC - relation type=sled

On 11/12/2022 13.10, Sven Geggus wrote: > This seems to be somewhat similar to the recent discussion about using > site-relations for camp-sites. > > Some people think that what I do in OpenCampingMap currently (using site > relations) is an abuse of the "One feature, one OSM element"

Re: [Tagging] scope of emergency=dry_riser_inlet

On Sun, 11 Dec 2022, 03:25 Kyle Hensel, wrote: > I think we need a new tag then. In New Zealand dry risers are not allowed > for new buildings, since charged systems are safer... > > > > François’s suggestion of emergency=riser_inlet + a sub tag seems like a > good idea, but is it possible to

Re: [Tagging] Feature Proposal - RFC - relation type=sled

Philipp Spitzer wrote: > I like to propose > https://wiki.openstreetmap.org/wiki/Relations/Proposed/Sled (which is > actually a quite old proposal) which tries to overcome the shortcomings > of piste:type=sled (without replacing it). > > I would be happy if you could provide

Re: [Tagging] Relations of type=site + tourism=camp_site

Jake Low wrote: > I would not recommend adding a node tagged tourism=camp_site into this > picture, as in my opinion it would be redundant with the site relation and > a violation of the "one feature, one OSM element" guideline. While this Approach would work well in OpenCampingMap, such

Re: [Tagging] scope of emergency=dry_riser_inlet

Call me old fashioned, but I think that we should only use "dry_riser_inlet" for the inlet to a riser that is... ...wait for it...   ...well, that is dry!  If that means that we needs few more tags to convey more information, then so be it. Regards,Peter PeterPan99 On Sunday, 11

Re: [Tagging] scope of emergency=dry_riser_inlet

Hi all To me, that sounds inappropriate to state dry/wet/charged in the emergency key. It is possible to refactor (here, improve) a value to best fit a wider range of situations, with a proposal and a review. In the dry_riser_inlet proposal, it was discussed to use "fire departement connection"

Re: [Tagging] plantation=yes?

On Dec 10, 2022, at 12:04 PM, Andy Townsend wrote: > On 10/12/2022 18:23, Mark Wagner wrote: >> As actually used on the map, "natural=wood" and "landuse=forest" are >> synonyms. >> > Depends on the map - if there are no other tags https://map.atownsend.org.uk > will show "landuse=forest" in a

Re: [Tagging] scope of emergency=dry_riser_inlet

I think we need a new tag then. In New Zealand dry risers are not allowed for new buildings, since charged systems are safer... François’s suggestion of emergency=riser_inlet + a sub tag seems like a good idea, but is it possible to deprecated an approved tag? Otherwise we need several main

Re: [Tagging] scope of emergency=dry_riser_inlet

sent from a phone > On 10 Dec 2022, at 10:35, Kyle Hensel wrote: > > However the wiki says “fire department connection” is a synonym of the tag. it is probably not always a synonym, it is if the riser is dry. ___ Tagging mailing list

Re: [Tagging] plantation=yes?

On 10/12/2022 18:23, Mark Wagner wrote: As actually used on the map, "natural=wood" and "landuse=forest" are synonyms. Depends on the map - if there are no other tags https://map.atownsend.org.uk will show "landuse=forest" in a lighter green to "natural=wood" (to indicate "forestry"; it also

Re: [Tagging] plantation=yes?

10 gru 2022, 19:23 od mark+...@carnildo.com: > On Sat, 10 Dec 2022 18:49:00 +0100 > Florian Lohoff wrote: > >> On Sat, Dec 10, 2022 at 01:10:33PM +, Dave F via Tagging wrote: >> > Hi >> > >> > What does plantation=yes represent? >> > Associated with woods, but nothing in the wiki. 2437 

Re: [Tagging] plantation=yes?

The usage of plantation=yes was discussed on the Carto repository recently: https://github.com/gravitystorm/openstreetmap-carto/issues/4721 It is also briefly mentioned on the wiki: https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dplantation -eginhard On Sat, Dec 10, 2022 at 7:26 PM Mark

Re: [Tagging] plantation=yes?

On Sat, 10 Dec 2022 18:49:00 +0100 Florian Lohoff wrote: > On Sat, Dec 10, 2022 at 01:10:33PM +, Dave F via Tagging wrote: > > Hi > > > > What does plantation=yes represent? > > Associated with woods, but nothing in the wiki. 2437  uses > > worldwide. Seems too vague to be OSM useful. >

Re: [Tagging] plantation=yes?

That was my thought at first. But maybe, forest as in "planted woodland" is not necessarily always for chopping down later, they might be planted for recreative purposes or for the air quality. Hard to tell from aerial view, though. On 10/12/2022 17:49, Florian Lohoff wrote: On Sat, Dec 10,

Re: [Tagging] plantation=yes?

On Sat, Dec 10, 2022 at 01:10:33PM +, Dave F via Tagging wrote: > Hi > > What does plantation=yes represent? > Associated with woods, but nothing in the wiki. 2437  uses worldwide. > Seems too vague to be OSM useful. Interesting - I would say natural=wood + plantation=yes is more likely

Re: [Tagging] Feature Proposal - RFC - relation type=sled

Dear Yves and Anne! Thanks for you comments! sled vs. sledding: I agree that sledding is a better word, however as "sled" is already used for piste:type I chose to stick to that. But sure it's easy to use something else. I think it will be hard to find a lot of support for a relation type

Re: [Tagging] plantation=yes?

Wood planted to be cut down as timber, I would imagine. They tend to be boring areas with little aesthetic or environmental benefit. How forests are tagged is a huge can of worms On Sat, 10 Dec 2022, 13:15 Dave F via Tagging, wrote: > Hi > > What does plantation=yes represent? > > Associated

[Tagging] plantation=yes?

Hi What does plantation=yes represent? Associated with woods, but nothing in the wiki. 2437  uses worldwide. Seems too vague to be OSM useful. DaveF ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - relation type=sled

I think it will be hard to find a lot of support for a relation type grouping sled runs, parking, restaurants, etc... All the additional features can be found easily in OSM: they are close to the run itself. For the walking parts, highway=path or else, or maybe piste:type=hike or connection

Re: [Tagging] scope of emergency=dry_riser_inlet

Hi Kyle It is true that sometimes the riser may be permanantly pressurised with main water. At least in France, we may find inlets on those pressurised risers http://www.formationssiap.fr/colonne-seche-colonne-humide-dit-charge/ We have clear labels "colonne seche" (dry riser) and "colonne

[Tagging] Feature Proposal - Approved - Street parking revision

I am happy to inform that the street parking revision proposal was accepted with 51 votes in favour, 2 votes against and 1 abstention. A new wiki page on street parking mapping has already been set up (https://wiki.openstreetmap.org/wiki/Street_parking) - it contains the new information from

Re: [Tagging] Feature Proposal - RFC - relation type=sled

Ah, fond childhood memories... Anyway, I was a bit confused about the word "sled", but I get it, now that I have seen the wiki page. How about calling it "sledding", though, in parallel to "walking" or "hiking"? https://en.wikipedia.org/wiki/Sledding Regards, Anne On 10/12/2022 09:11, Philipp

[Tagging] scope of emergency=dry_riser_inlet

Hi, The tag emergency=dry_riser_inlet contains the word “Dry”, which suggests that it can only be used for inlets into _dry_ riser systems. However the wiki says “fire department connection” is a synonym of the tag. This suggests that the `emergency=dry_riser_inlet` can be used for other types

Re: [Tagging] Feature Proposal - RFC - relation type=sled

Why not https://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste ? Sled is already documented and used for those relations. Regards, Yves Le 10 décembre 2022 10:11:39 GMT+01:00, Philipp Spitzer a écrit : >Dear all! > >I like to propose https://wiki.openstreetmap.org/wiki/Relations/Proposed/Sled

[Tagging] Feature Proposal - RFC - relation type=sled

Dear all! I like to propose https://wiki.openstreetmap.org/wiki/Relations/Proposed/Sled (which is actually a quite old proposal) which tries to overcome the shortcomings of piste:type=sled (without replacing it). I would be happy if you could provide thoughts/comments in the corresponding

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

Le 07.12.22 à 07:31, Warin a écrit : On 7/12/22 01:54, Marc_marc wrote: Le 06.12.22 à 00:47, Graeme Fitzpatrick a écrit : https://lists.openstreetmap.org/pipermail/tagging/2022-November/066540.html Are there any further comments that anybody would like to raise? I have not issue with

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On 6/12/22 21:51, Tom Pfeifer wrote: Still does not resolve my problem with a water rescue station where there is no boat. I don't see a requirement for a boat? https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlifeboat_station Specifically mentions other things like helicopters.

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On 7/12/22 01:54, Marc_marc wrote: Le 06.12.22 à 00:47, Graeme Fitzpatrick a écrit : https://lists.openstreetmap.org/pipermail/tagging/2022-November/066540.html Are there any further comments that anybody would like to raise? I have not issue with merging 3-4 tags with the same meaning

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On Wed, 7 Dec 2022 at 00:57, Marc_marc wrote: > > - what are we mapping ? reading the description, this seems to be more > of a landuse=ermergency than mapping an emergency service i.e. where > you can go to get a service > The land-based location of emergency groups dedicated to the saving of

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

On Tue, 6 Dec 2022 at 20:54, Tom Pfeifer wrote: > Still does not resolve my problem with a water rescue station where there > is no boat. > > Before people ask again how that is possible - they might have their boats > mooring at changing > locations without a station, but the station is not

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

Le 06.12.22 à 00:47, Graeme Fitzpatrick a écrit : https://lists.openstreetmap.org/pipermail/tagging/2022-November/066540.html Are there any further comments that anybody would like to raise? I have not issue with merging 3-4 tags with the same meaning but : - what are we mapping ? reading

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

Still does not resolve my problem with a water rescue station where there is no boat. Before people ask again how that is possible - they might have their boats mooring at changing locations without a station, but the station is not directly at one of the rivers/lakes. tom On 06.12.2022

[Tagging] RFC - Proposed features/emergency=lifeboat station

Bringing this forward to the new month. https://lists.openstreetmap.org/pipermail/tagging/2022-November/066540.html Are there any further comments that anybody would like to raise? To sum-up, proposal is to: Approve emergency=lifeboat_station Deprecate emergency=marine_rescue & merge it's

[Tagging] Feature Proposal - Approved - archaeological_site

Hello all, the proposal has been approved with 20 pro and 4 contra votes. Thank you all who took part in the discussion and the vote! Cheers, Anne ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Snow chains

This Proposal includes: Tags related to snow chains: * Restrictions on roads regarding snow chains, with optional applying conditions and if they are variable (not active throughout the whole year) * Places to put on/off snow chains (which are dedicated and maybe parking restrictions apply)

Re: [Tagging] Feature Proposal - Voting - historic

Martin's "reply to some unilaterally writing on the key:historic page..." and "intended to say (something extraordinary) on one end and on the other end (something vague)" sort of "nudge ahead" this dizzying proposal, but not by much. I'm not complaining at the extra clarification. But it

Re: [Tagging] Feature Proposal - Voting - historic

sent from a phone > On 4 Dec 2022, at 11:41, Martin Koppenhoefer wrote: > > only for features that are considered of historical significance. intended to say, “of extraordinary historical significance” on the one end, and the opposing direction is more like “generally somehow related to

Re: [Tagging] Feature Proposal - Voting - historic

sent from a phone > On 4 Dec 2022, at 10:57, Frederik Ramm wrote: > > "This key can be used on every observable feature that has a historical > meaning, regardless of ... interest to the OSM community." I believe this is in reply to some unilaterally writing on the key:historic page of

Re: [Tagging] Feature Proposal - Voting - historic

This proposal, its history, its present and its future I find extremely confusing. It is enough for me to vote it down because it needs to be started from scratch (the proposal itself, not the voting on what is now too confusing a proposal). If we are re-voting, I'm not even sure I can find

Re: [Tagging] Feature Proposal - Voting - historic

Ah, I see now I put this in my vote on the 2nd voting round. -- I also see that I asked there why abandoned railways were mentioned since I thought they had their own key and wern't using "historic", is this an intentional change? Is the re-tagging of abandoned railways proposed here? On

Re: [Tagging] Feature Proposal - Voting - historic

Hi, I could swear I had written this as a public message long ago but I cannot find it now. Sorry, then, for the last-minute interruption. I had an issue with the proposal, namely the wording: "This key can be used on every observable feature that has a historical meaning, regardless of ...

Re: [Tagging] Door tag

On 03.12.22 at 02:46 Kyle Hensel wrote: Can we change the wiki so that it says “*/An/* entrance tag” instead of “*/The/* entrance=* tag”? It's also ok to use door=* without any additional entrance tag. This is used with Simple Indoor Tagging, as indoor=door isn't actually part of SIT.

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

On 03.12.2022 11:49, Alex wrote: _Mainly_, I have concerns about the concept of a cycle path or foot path being attendant to or a sidepath of another road. In Norway, we no longer have cycle paths and foot paths. We have cycleways, footways and carriageways. It may seem like a small

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

_Mainly_, I have concerns about the concept of a cycle path or foot path being attendant to or a sidepath of another road. In Norway, we no longer have cycle paths and foot paths. We have cycleways, footways and carriageways. It may seem like a small difference in terminology, but it makes

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

The whole proposal is a pragmatic compromise to the fact that we do not have an usable solution for "grouping" paths within a road corridor. As we know, relations cannot be used effectively for this at present (if we are already talking about the "effort" to tag a sidepath with a single

Re: [Tagging] Door tag

sent from a phone > On 3 Dec 2022, at 02:50, Kyle Hensel wrote: > > Can we change the wiki so that it says “An entrance tag” instead of “The > entrance=* tag”? > > > ok, or maybe “door” could simply mean “the type of a door”? Do we even need this qualifier with “entrance” at all?

[Tagging] Door tag

Hi, I’ve just noticed that https://wiki.osm.org/Key:door says “The door=* tag must be used in conjunction with the entrance=* tag on buildings” This claim doesn’t reflect how the tag is actually used. Someone realized this and recently amended that statement to note that Simple Indoor Tagging

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

On 02.12.2022 13:31, Alex wrote: Paths and ways along a road can be mapped separately in OSM, but those separate geometries cannot be identified as part of the road, or only with the significant effort of using geometric processing (which most applications can't perform). I strongly agree

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

2 gru 2022, 20:50 od m...@nguyen.cincinnati.oh.us: > Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết: > >> I have good news! There is preprocessing solution for large (nearly all?) >> simple cases, >> written in Kotlin and is a part of StreetComplete. >> >> StreetComplete

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

Vào lúc 07:54 2022-12-02, Tobias Knerr đã viết: On 02.12.22 15:02 Mateusz Konieczny wrote: If it is second case of preprocessing being impossible - why do massive duplication and ask to duplicate ref value AND name value AND highway value? The duplication-free solution of referencing the

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết: I have good news! There is preprocessing solution for large (nearly all?) simple cases, written in Kotlin and is a part of StreetComplete. StreetComplete would be able to handle cases listed in its sidewalk detection (used to

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

2 gru 2022, 16:54 od o...@tobias-knerr.de: > On 02.12.22 15:02 Mateusz Konieczny wrote: > >> Or is it justifiable because it is outright impossible to do reliably >> with automatic preprocessing? >> > > I would say that's the reason. Of course, it's hard to prove that something > is

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

On 02.12.22 15:02 Mateusz Konieczny wrote: Or is it justifiable because it is outright impossible to do reliably with automatic preprocessing? I would say that's the reason. Of course, it's hard to prove that something is impossible. But so far no one has built a working solution for

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

"or only with the significant effort of using geometric processing (which most applications can't perform)" why doing it manually would be preferable? Is it repeating mistake of adding pointless work for mappers because it "causes extra preprocessing for routing software."? And valuing time

[Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

Paths and ways along a road can be mapped separately in OSM, but those separate geometries cannot be identified as part of the road, or only with the significant effort of using geometric processing (which most applications can't perform). However, the information whether a path is attendant

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

2022-12-01 23:37 skrev Minh Nguyen: Vào lúc 02:08 2022-12-01, Volker Schmidt đã viết: This proposal is incorrectly giving the impression that it is in the spirit of the crossing:markings tag. This tag was meant to complement and refine the existing tagging of crossings in some cases, but

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 02:08 2022-12-01, Volker Schmidt đã viết: This proposal is incorrectly giving the impression that it is in the spirit of the crossing:markings tag. This tag was meant to complement and refine the existing tagging of crossings in some cases, but certainly not to replace, wholesale the

Re: [Tagging] care services

Hello, I created a wiki page https://wiki.openstreetmap.org/wiki/Tag:office%3Dpersonal_service with some suggestions of subtags. Any feedback, suggestion, correction is most welcome. Thanks. ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

This proposal is incorrectly giving the impression that it is in the spirit of the crossing:markings tag. This tag was meant to complement and refine the existing tagging of crossings in some cases, but certainly not to replace, wholesale the "crossing" key The crossing:markings key describes the

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

sent from a phone > On 30 Nov 2022, at 18:53, Mateusz Konieczny via Tagging > wrote: > > https://www.openstreetmap.org/node/3586404853 > (and not tagged with anything directly indicating that) fix it :)___ Tagging mailing list

[Tagging] Feature Proposal - Approved - Manufacturer and Model

Hello all, Voting has finished for the proposal "Manufacturer and Model" ( https://wiki.openstreetmap.org/wiki/Proposed_features/Manufacturer_and_Model ), the proposal has been approved: - manufacturer:type=* will be deprecated in favor of model=* - vehicle:wikidata=* will be deprecated in

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

30 lis 2022, 14:02 od dieterdre...@gmail.com: > Am Mi., 30. Nov. 2022 um 01:10 Uhr schrieb Mateusz Konieczny via Tagging <> > tagging@openstreetmap.org> >: > >> >> >> 29 lis 2022, 22:55 od >> dieterdre...@gmail.com>> : >> >>> >>> >>> sent from a phone >>> On 29 Nov 2022, at 09:02,

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Am Mi., 30. Nov. 2022 um 01:10 Uhr schrieb Mateusz Konieczny via Tagging < tagging@openstreetmap.org>: > > 29 lis 2022, 22:55 od dieterdre...@gmail.com: > > > > sent from a phone > > On 29 Nov 2022, at 09:02, Mateusz Konieczny via Tagging < > tagging@openstreetmap.org> wrote: > > "no traffic

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

29 lis 2022, 22:55 od dieterdre...@gmail.com: > > > sent from a phone > >> On 29 Nov 2022, at 09:02, Mateusz Konieczny via Tagging >> wrote: >> >> "no traffic signals" applies also only in some jurisdictions >> > > > If there are traffic signals the crossing in OpenStreetMap gets tagged >

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

sent from a phone > On 29 Nov 2022, at 11:06, Minh Nguyen wrote: > > What was the problem with crossing_ref=zebra again? it’s applied to signal controlled crossings as well when they have zebra road markings. > > What you seem to be suggesting is that the definition of crossing=zebra >

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

sent from a phone > On 29 Nov 2022, at 09:02, Mateusz Konieczny via Tagging > wrote: > > "no traffic signals" applies also only in some jurisdictions If there are traffic signals the crossing in OpenStreetMap gets tagged crossing=traffic_signals, this is regardless of jurisdiction AFAIK.

[Tagging] Feature Proposal - Approved - Tag:amenity=mailroom

Tag:amenity=mailroom was approved to mark a mailroom for receiving packages or letters at a university, an apartment building complex, or a commercial office building complex. The tag is added either to a building outline or to a node denoting the specific location of the mailroom.

Re: [Tagging] ****SPAM:6.1**** Re: Feature Proposal - RFC - Crossing cleanup and deprecation

On 29/11/2022 10:01, Minh Nguyen wrote: Vào lúc 23:01 2022-11-28, Martin Koppenhoefer đã viết: On 29 Nov 2022, at 00:52, Minh Nguyen wrote: Even if it weren't for iD's long-gone preset, I don't think an ostensibly global tag should be defined based on the narrow provisions of a specific

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

In Nederland, zebra or zebra-path means just the striped pattern. No signs or signals are implied. It's the only named type of crossing*, everybody knows it. crossing=zebra is perfect for that; WYSIWIM (What You See Is What You Map). Very straightforward. Signals and signs may be present, but

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 23:01 2022-11-28, Martin Koppenhoefer đã viết: On 29 Nov 2022, at 00:52, Minh Nguyen wrote: Even if it weren't for iD's long-gone preset, I don't think an ostensibly global tag should be defined based on the narrow provisions of a specific country's laws. I don’t think this is

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

29 lis 2022, 00:18 od dieterdre...@gmail.com: > Crossing=zebra is about a zebra crossing, it implies also vertical signs- in > some jurisdictions and some conditions at least - and it implies that there > aren’t traffic signals. > "no traffic signals" applies also only in some jurisdictions

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

sent from a phone > On 29 Nov 2022, at 00:52, Minh Nguyen wrote: > > Even if it weren't for iD's long-gone preset, I don't think an ostensibly > global tag should be defined based on the narrow provisions of a specific > country's laws. I don’t think this is about a specific country,

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 15:18 2022-11-28, Martin Koppenhoefer đã viết: crossing:markings is just about this, road markings, and while crossing_ref=zebra wasn’t documented for a long time, people that added it around here told me it was about the presence of road markings as well. Crossing=zebra is about a

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

sent from a phone > On 28 Nov 2022, at 23:53, Minh Nguyen wrote: > > If we keep crossing=zebra around based on the argument [1] that it takes > fewer keystrokes or clicks than adding crossing_ref=zebra or > crossing:markings=zebra without using a preset, then this undermines the >

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 04:55 2022-11-28, Martin Koppenhoefer đã viết: Just because there is a now a way to map crossing markings separate from other properties, does not imply all the tagging we have is not needed any more, rather I would see "crossing:markings" as implicit, for example on a

<    9   10   11   12   13   14   15   16   17   18   >