Re: [Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter
I've drafted a proposal for natural=rock_overhang at https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Drock_overhang please provide any feedback or suggestions. On Mon, 26 Oct 2020 at 15:10, Andrew Harvey wrote: > Voting is closed now with 8 yes, 8 no, 2 abstain. no clear consensus here > so marked as rejected. > > Reviewing those against, a common theme is the view that amenity=shelter > should be reserved for purpose built/man made shelters and not natural > features commonly used as a place of shelter. > > I'm still keen to have an approved way to map these features and avoid the > current situation where two different kinds of features are commonly mapped > using the same tag leaving no way to distinguish them. > > So with this voting feedback in mind I'll move ahead with a new proposal > for natural=rock_overhang. > > On Mon, 12 Oct 2020 at 10:34, Andrew Harvey > wrote: > >> >> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter >> is >> open for voting now. >> > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Tag:shelter_type=rock_shelter
Voting is closed now with 8 yes, 8 no, 2 abstain. no clear consensus here so marked as rejected. Reviewing those against, a common theme is the view that amenity=shelter should be reserved for purpose built/man made shelters and not natural features commonly used as a place of shelter. I'm still keen to have an approved way to map these features and avoid the current situation where two different kinds of features are commonly mapped using the same tag leaving no way to distinguish them. So with this voting feedback in mind I'll move ahead with a new proposal for natural=rock_overhang. On Mon, 12 Oct 2020 at 10:34, Andrew Harvey wrote: > > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter > is > open for voting now. > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 2020-10-25 15:47, Allroads wrote: > All landuse what is used for legally public roads, laid down in a zoning plan > by the Government "bestemmingsplan" should be called landuse=highway no, > because the content of a bestemmingsplan is what is politically desired and > legally permitted, it is a plan. Landuse is not about the zoning plan, it is > about the actual current landuse, regardless of its compatibility with the > legal situation. That's the irrevocable plan, then all is shaped. There can be a considerable amount of time between the approval of a "bestemmingsplan" and its actual implementation in the case of certain properties. When a plan is changed (a political decision) this gives rise to claims for damages, and official waivers for the current status (that may only apply to the current residents for example). There are lots of ways in which the reality can legally diverge from the "bestemmingsplan". As OSM prefers the reality to the theory, a zoning plan can only be an indication. It will however often be in line with reality.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
as an additional datapoint shop=ticket is the only one with significant usage: (15000) https://taginfo.openstreetmap.org/search?q=ticket#values From its definition, it could also not be suitable (unclear), or maybe it is? https://wiki.openstreetmap.org/wiki/Tag%3Ashop%3Dticket vending=admission_tickets also has some usage: (189) https://taginfo.openstreetmap.org/search?q=admission#values and rarely ticket=admission (10 times) Cheers, Martin sent from a phone___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Special Economic Zones
That is an excellent point - perhaps a better definition would say: "A *special economic zone (SEZ)* is a government-defined area in which business and trade laws are different." This leaves the scope open and allows for future subtagging for future specificity. On Sun, Oct 25, 2020 at 10:39 AM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 25. Oct 2020, at 15:24, Brian M. Sperlongano > wrote: > > > > The point is to provide a standard, non-cryptic, foundational tag for > such areas. Perhaps future proposals might further propose tagging for > which level of government has declared the SEZ, or the type of SEZ, or any > other aspect of an SEZ that might be appropriate for OSM tagging. > > > My questions were aiming at helping you to find a suitable definition, > because the word “country” limits the scope to specific situations, and > this is not something that could be fixed later with subtagging. > > Cheers Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
All landuse what is used for legally public roads, laid down in a zoning plan by the Government "bestemmingsplan" should be called landuse=highway no, because the content of a bestemmingsplan is what is politically desired and legally permitted, it is a plan. Landuse is not about the zoning plan, it is about the actual current landuse, regardless of its compatibility with the legal situation. That's the irrevocable plan, then all is shaped. For Netherlands law https://wetten.overheid.nl/BWBR0006622/2020-10-01 describing what belongs to a road. " wegen: alle voor het openbaar verkeer openstaande wegen of paden met inbegrip van de daarin liggende bruggen en duikers en de tot die wegen behorende paden en bermen of zijkanten; " " roads: all roads or paths open to public traffic, including bridges and culverts situated therein and the paths and verges or sides belonging to those roads; " All landuse=highway. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Special Economic Zones
sent from a phone > On 25. Oct 2020, at 15:24, Brian M. Sperlongano wrote: > > The point is to provide a standard, non-cryptic, foundational tag for such > areas. Perhaps future proposals might further propose tagging for which > level of government has declared the SEZ, or the type of SEZ, or any other > aspect of an SEZ that might be appropriate for OSM tagging. My questions were aiming at helping you to find a suitable definition, because the word “country” limits the scope to specific situations, and this is not something that could be fixed later with subtagging. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
On 25-10-2020 14:55, Janko Mihelić wrote: > Relations are definitely safer, but I wanted to add a unique name > version for new editors that are intimidated by relations. > Also for cases when you would have a lot of admission issuers, so we > don't get some humongous relations. Maybe there's a venue for which you > can buy a ticket in any kiosk in town. I would rather tag something like > that with a admission:name=* than add all kiosks to a relation. Using relations for the first time is tricky, you are right about that. But there are a lot of places in OSM where relations are necessary. I wouldn't worry too much about novice mappers not being able to use them. Any mapper who can use the wiki to look up keys for a scheme like this will probably be able to use JOSM to create relations. When the proposal is settled down on the relation type and roles a prefix could be created for JOSM to help create such a relation, further lowering the bar. I wouldn't be too afraid of large relations, but you might want to add that the ticket office and the poi should (ideally) be geographically close-ish (like, within the same city or area). This is similar to what the site-relation documentation states. I mentioned this on the wiki as well: it might be nice to add an optional role to your relation for the actual entrances (e.g., turnstiles), in addition to the ticket office and the poi, where tickets are checked. For something like a theme park these are definitely mapped, and a clever router could suggest a route going from the ticket office to an entrance with that data available. This looks like a useful proposal. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Special Economic Zones
SEZs are certainly not de facto. By definition, they are defined by laws that apply only to a certain area. Therefore, they are both defined by a government, and have defined geographic limits. As to whether an SEZ is defined by a national government, or a sub-national government, that question is irrelevant. The definition works just fine regardless of which government entity passes the law creating the SEZ. The point is to provide a standard, non-cryptic, foundational tag for such areas. Perhaps future proposals might further propose tagging for which level of government has declared the SEZ, or the type of SEZ, or any other aspect of an SEZ that might be appropriate for OSM tagging. This proposed tagging leaves open the possibility for future extensions. And finally, to the question of "who decides if it is an SEZ", that is a task correctly left to local mapping communities. By community editing, Wikipedia has managed to muster a considerable list of these zones in https://en.wikipedia.org/wiki/List_of_special_economic_zones, and we should equally trust that local communities are capable of deciding what tagging may or may not be appropriate in different countries. On Sun, Oct 25, 2020 at 6:59 AM Martin Koppenhoefer wrote: > > > Am So., 25. Okt. 2020 um 05:34 Uhr schrieb Brian M. Sperlongano < > zelonew...@gmail.com>: > >> A special economic zone (SEZ) is an area in which the business and trade >> laws are different from the rest of the country. Only a small number of >> these areas are mapped so far, however, estimates put the total number of >> SEZ worldwide at between 2,700 and 10,000. The proposed tagging for these >> areas is boundary=special_economic_zone, which has minor existing usage. >> > > > who is it who defines this status, is it defacto or does the national > government have to define these? What if the business and trade laws are > not defined on a national level? Which "business and trade laws" are meant > (does any exception to a "business or trade" law in a are lead to the > (implicit) constitution of such a zone? Which laws are relevant?). What if > the national government does not control the area? > > I agree that for those cases, where the zone is explicitly defined by a > national government, this would be easy to determine, but all other cases > which might fall under the definition, are harder to decide. > > Cheers > Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
sent from a phone > On 25. Oct 2020, at 14:41, Allroads wrote: > > All landuse what is used for legally public roads, laid down in a zoning plan > by the Government "bestemmingsplan" should be called landuse=highway no, because the content of a bestemmingsplan is what is politically desired and legally permitted, it is a plan. Landuse is not about the zoning plan, it is about the actual current landuse, regardless of its compatibility with the legal situation. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
On Sun, Oct 25, 2020, 12:59 Martin Koppenhoefer wrote: > An alternative idea could be to use the type=site relation, add the ticket > office with an appropriate role to the relation (e.g. "sells_tickets"). > Maybe the term "sells" should be omitted, because sometimes you need a > ticket, but it is free (e.g. to control the number of people you let in, or > to get an idea how many people have entered, even if there aren't safety > reasons). > Maybe admission_issuer. But you also need a role for the place you need an admission for. You probably wanted to add it in a site relation so you don't have two relations, but I think it would just generate problems. Maybe I'm wrong. That could be a separate proposal. If we do this, I would prefer a strong relation between the feature and the > ticket office, not just by the name, but with explicit links (a relation). > Relations are definitely safer, but I wanted to add a unique name version for new editors that are intimidated by relations. Also for cases when you would have a lot of admission issuers, so we don't get some humongous relations. Maybe there's a venue for which you can buy a ticket in any kiosk in town. I would rather tag something like that with a admission:name=* than add all kiosks to a relation. Thanks for your opinion! > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
For me, the value "parking_space" what key, single space problem must be fixed first to say something about "street_side". As it comes to a vote. Could you elaborate? amenity=parking_space can be used as usual within amenity=parking. This of course also works with amenity=parking/parking=street_side: https://www.openstreetmap.org/way/849745989 Our proposal doesn't affect the documented use of amenity=parking_space; you would use it just the same as with parking=surface. Reading parts over the years about parking. A lot of people do no see amenity=parking as a good tag for street side parking. Mainly prompted by wiki (image) en carto, the visualisation of P. https://wiki.openstreetmap.org/wiki/Parking street side parking is the only method in given on this page. The main tag covering most conventional car parks, coach parks etc. Many additional tags are listed on this page. We will always have that opposition. Also a question for me, must we split the tagging there, when we still can. amenity is mostly with a sign https://wiki.openstreetmap.org/w/images/thumb/8/80/NLE04.gif/60px-NLE04.gif amenity=parking_space can only be tagged on a amenity=parking? https://www.openstreetmap.org/relation/11650954#map=19/53.21448/5.80418 Why is this a relation and not only polygon tagging. (That is a other discussion, but rubs against it) If some, we, not use amenity=parking, how to tag the parking_space as a value? There spots, where people park in the verge, on the grass, or other surface grass_paver, what is permitted. In or outside the residential area. ( "bebouwde kom") https://wiki.openstreetmap.org/w/images/thumb/b/bc/NLE01.gif/60px-NLE01.gif have not a effect on the verge, the EU rule is no_parking on the carriageway. The operating force of a traffic sign may not be expanded. https://upload.wikimedia.org/wikipedia/commons/thumb/8/8b/Nederlands_verkeersbord_B1.svg/60px-Nederlands_verkeersbord_B1.svg.png. Outside the residential area "bebouwde kom" it is prohibited to park on the carriageway, but not on the verge. How do we do that with parking, amenity=parking? Also the structure of the area:highway methodology, which needs to be further developed in detail. All landuse what is used for legally public roads, laid down in a zoning plan by the Government "bestemmingsplan" should be called landuse=highway, inside this polygon the objects are area:highway https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway https://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines There is area:highway=traffic_island https://overpass-turbo.eu/s/Znt there should be area:highway=verge, the busbay is also not well documented. https://wiki.openstreetmap.org/wiki/Key:shoulder the polygon equivalent is area:highway=shoulder. https://wiki.openstreetmap.org/wiki/Key:verge the polygon equivalent is area:highway=verge (verge:access:motorcar=no when parking on the verge is expressly prohibited.) But there is this used area:highway=parking_space, and not for only one space. What a space should be. https://wiki.openstreetmap.org/w/images/4/42/MarekXjunctionExampleWithTagging.jpg area:highway is a used key. All these parking area, should get a tag area:highway, but which? Or both amenity=parking. Or is amenity parking only for lots. https://overpass-turbo.eu/s/Zns ["area:highway"="parking_space"] or is it area:highway=service service=parking_space if it is one space, with multiple not drawn in space, service=parking. That is why I wrote. For me, The search for good cohesion. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal for admission=* tag
I think it would be generally useful to add this kind of information, not only when the ticket office is spatially distant from the feature, but in every case where a ticket is needed. An alternative idea could be to use the type=site relation, add the ticket office with an appropriate role to the relation (e.g. "sells_tickets"). Maybe the term "sells" should be omitted, because sometimes you need a ticket, but it is free (e.g. to control the number of people you let in, or to get an idea how many people have entered, even if there aren't safety reasons). If we do this, I would prefer a strong relation between the feature and the ticket office, not just by the name, but with explicit links (a relation). Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Special Economic Zones
Am So., 25. Okt. 2020 um 05:34 Uhr schrieb Brian M. Sperlongano < zelonew...@gmail.com>: > A special economic zone (SEZ) is an area in which the business and trade > laws are different from the rest of the country. Only a small number of > these areas are mapped so far, however, estimates put the total number of > SEZ worldwide at between 2,700 and 10,000. The proposed tagging for these > areas is boundary=special_economic_zone, which has minor existing usage. > who is it who defines this status, is it defacto or does the national government have to define these? What if the business and trade laws are not defined on a national level? Which "business and trade laws" are meant (does any exception to a "business or trade" law in a are lead to the (implicit) constitution of such a zone? Which laws are relevant?). What if the national government does not control the area? I agree that for those cases, where the zone is explicitly defined by a national government, this would be easy to determine, but all other cases which might fall under the definition, are harder to decide. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 22:27, Allroads wrote:> Use area:highway for polygon and parking! I will clarify the relation of our proposal to area:highway, thanks for pointing it out. In brief, the two tagging methods coexist and complement each other. Our proposal focuses on the parking-amenity (and thus amenity=parking) aspect of these street-side parking areas. Anyone mapping with area:highway can of course use amenity=parking|parking=street_side, and either: * include the parking areas within a area:highway=residential or similar; * use area:highway=service; * or not include them within the highway area and leave them as-is. What the right approach is, is probably beyond the scope of our proposal, and should be discussed within the scope of the area:highway proposals instead. I think it suffices to say that amenity=parking|parking=street_side complements area:highway mapping if applied, but doesn't require it. > For me, the value "parking_space" what key, single space problem must > be fixed first to say something about "street_side". As it comes to a vote. Could you elaborate? amenity=parking_space can be used as usual within amenity=parking. This of course also works with amenity=parking/parking=street_side: https://www.openstreetmap.org/way/849745989 Our proposal doesn't affect the documented use of amenity=parking_space; you would use it just the same as with parking=surface. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 23:54, Paul Allen wrote: > So tagging for the renderer because, in your opinion, these car parking > areas are unimportant. By that line of reasoning tagging highways anything other than highway=motorway is tagging for the renderer. I understand your concern, but no, it is not our opinion that these car parking areas are unimportant (we wouldn't map them if we thought so). This proposal is not about declaring one type of parking more important than the other. It does standardise a new parking=* and parking:lane=* value for a distinct, commonly mapped, and ubiquitous type of parking area. Because of the way these features are present on the ground, it makes sense for a renderer to consider a different rendering approach than they would for a parking garage of parking lot. And yes, for a general purpose map, that may involve de-emphasizing them. In the Netherlands we've had a case where a misguided mapper imported this type of street-side parking area in one city (the import was not properly discussed and documented and has since been reverted). They used amentity=parking_space on those areas instead of amenity=parking (even though most contained at least two parking spaces), because they didn't like the way amenity=parking rendered on Carto with hundreds of parking areas mapped. That is tagging for the renderer. We want to prevent that. By introducing a relevant sub-tag value renderers and routers may act on, we prevent tagging for the renderer, and encourage the use of a semantically correct tag-value. A collatoral effect is that the existing parking=* values will become less abused (e.g., surface and layby) for street-side parking. Mappers who want to map street-side parking, can do so knowing that any rendering issues can be dealt with by any renderer on the base of the correct sub-tag value. Whether renderers will act on this or not is of course a stylistic choice not part of this proposal, but we do offer some suggestions (under 'Rendering'). Of course, I can fully imagine some types of map or overlay that actively highlight street-side parking! For example some sort of 'parking-mode' on a router's screen when you are nearing your destination. Similarly, some users may prefer street-side parking over parking garages (camper/RV owners perhaps), and instruct their router to filter on those. Our proposal facilitates this: renderers can render street-side parking however they wish, because the tag tells them it is street-side parking. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
