Re: [Tagging] How to tag shop areas in a shopping mall ?
sent from a phone > On 24. Jan 2018, at 22:01, André Pirard wrote: > > The advantage of a node is best seen when you try to add several shops tags > to the same building/area: a nightmare. with the level tag and josms level filtering it is possible to keep things clear. With multipoligon relations you can have overlapping areas that are easy to edit. > Doing it with a number of nodes is just straightforward. it often leads to completely symbolic representations for routing, see for example here: www.openstreetmap.org/note/1232585 when shops in a mall are mapped as areas they are usually much better positioned, and not arbitrarily like nodes in many cases, and you can also see which one is big and which is small. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag shop areas in a shopping mall ?
sent from a phone > On 24. Jan 2018, at 20:46, OSMDoudou > <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote: > > But as they're asking to maintain their shops tagged as node, this is > effectively asking the community refrains itself from improving the tagging > of the mall As areas and nodes are both valid representations for a shop, I would say they should adopt to it and handle both kind of elements, not insisting on nodes. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag shop areas in a shopping mall ?
On 2018-01-24 20:46, OSMDoudou wrote: > > Following the discussion here, I changed the mapping of the mall to > move tags from individual nodes to an area. > > > > For one shop, it attracted feedback from the commercial entity who > maintains its data on OpenStreetMap saying the change broke something > at their side. See the discussion on the changeset: [1]. > > > > I'm very glad a company enriches the map and actively maintains the > data (1700 nodes, they say), so I really want to support them and I > reverted the change. > > > > But as they're asking to maintain their shops tagged as node, this is > effectively asking the community refrains itself from improving the > tagging of the mall (following the idea that shops are better mapped > as areas than nodes), and this is not in the interest of the community > (which is to have a complete, coherent, accurate and maintained > mapping of the place). > > > > So, I wanted to ask your views on how to deal with this situation. > A shop is, as surprising as it may seem, not a building but an activity that takes place somewhere. In a conventional building or anywhere: in a tent, in a hall, on the side of the street etc. It can be tagged on a building or any area or on a node inside it, which is the preference that I see around here. The advantage of a node is best seen when you try to add several shops tags to the same building/area: a nightmare. Doing it with a number of nodes is just straightforward. Also, a node is usable if you know too little of the geometry of the area to map it decently. I have often drawn buildings around shop nodes that were already there. It's really nice to see people map their belongings. Usually, the opposite happens: they completely ignore messages telling them it has been done. Cheers André. > > > [1] > https://www.openstreetmap.org/changeset/55640175#map=19/50.45645/3.93247 > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag shop areas in a shopping mall ?
If of course all of their shops are mapped in detail as areas, they still get a consistent target. -- Andrew From: OSMDoudou <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> Sent: 24 January 2018 19:46:26 To: 'Tag discussion, strategy and related tools' Subject: Re: [Tagging] How to tag shop areas in a shopping mall ? Following the discussion here, I changed the mapping of the mall to move tags from individual nodes to an area. For one shop, it attracted feedback from the commercial entity who maintains its data on OpenStreetMap saying the change broke something at their side. See the discussion on the changeset: [1]. I'm very glad a company enriches the map and actively maintains the data (1700 nodes, they say), so I really want to support them and I reverted the change. But as they're asking to maintain their shops tagged as node, this is effectively asking the community refrains itself from improving the tagging of the mall (following the idea that shops are better mapped as areas than nodes), and this is not in the interest of the community (which is to have a complete, coherent, accurate and maintained mapping of the place). So, I wanted to ask your views on how to deal with this situation. [1] https://www.openstreetmap.org/changeset/55640175#map=19/50.45645/3.93247 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag shop areas in a shopping mall ?
Following the discussion here, I changed the mapping of the mall to move tags from individual nodes to an area. For one shop, it attracted feedback from the commercial entity who maintains its data on OpenStreetMap saying the change broke something at their side. See the discussion on the changeset: [1]. I'm very glad a company enriches the map and actively maintains the data (1700 nodes, they say), so I really want to support them and I reverted the change. But as they're asking to maintain their shops tagged as node, this is effectively asking the community refrains itself from improving the tagging of the mall (following the idea that shops are better mapped as areas than nodes), and this is not in the interest of the community (which is to have a complete, coherent, accurate and maintained mapping of the place). So, I wanted to ask your views on how to deal with this situation. [1] https://www.openstreetmap.org/changeset/55640175#map=19/50.45645/3.93247 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Piste:type=connection
Hi Marc, I did send an RFC, over a year ago: https://lists.openstreetmap.org/pipermail/tagging/2016-September/030270.html Caused some positive comments on the discussion page and quite some people actually using the tag. As for the text on the proposal page itself: I intended it for the audience here. I agree that the tag description for a general mappers' audience needs to be different. (Not very familiar with the proposal habits.) I promise to draft a better tag page after voting ;-) Helge >marc marc marc_marc_irc at hotmail.com wrote: >Wed Jan 24 10:04:39 UTC 2018 > >Hello, > >Le 24. 01. 18 à 10:42, Helge Fahrnberger a écrit : >> https://wiki.openstreetmap.org/wiki/Proposed_features/Piste:type%3Dconnection >> I'd like to start voting > >you forget to make a request for comment :) >end end date look wrong (January <> February) >my comment : the definition is strange. >"mainly for routing purposes" is not a definition, it's a usecase. >Maybe definition should be like : >"ways taken by skiers to go from one lift to another or >from one lift to another at the beginning of the piste." > >Regards, ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] AutoEdit rename roof:slope:direction to roof:direction
Here the missing overpass links for "roof:ridge:direction". gabled -> 1120 ways https://overpass-turbo.eu/s/vks hipped -> 100 ways https://overpass-turbo.eu/s/vku half-hipped -> 68 ways https://overpass-turbo.eu/s/vkv gambrel -> 9 ways https://overpass-turbo.eu/s/vkw round -> 1 way https://overpass-turbo.eu/s/vkx mansard -> 8 ways https://overpass-turbo.eu/s/vky saltbox -> 0 ways Regards, Rebo ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed features - Voting - Pressurized waterways
Le 23. 01. 18 à 14:25, Mateusz Konieczny a écrit : > I would prefer waterway=canal + pressurised=yes + tunnel=* rather > than waterway=pressurised. trivial in appearance, this change would imply a huge change of meaning. today common sense is that waterway=canal is a canal :-) thus not pressurized. your modification would mean that waterway=canal is either a canal or pressurized. it implies that 300,000 objects would have to be reviewed to add the lost information. and each time a contributor forgets the pressurised tag, we won't know if he saw a channel or a pipeline, which is still 2 totally different objects. or we have to assume he saw the most common object. it's really not a good solution for data quality. Le 24. 01. 18 à 12:02, François Lacombe a écrit : > Why free flow should get a waterway and pressurised none ? > I find this confusing. I agree. it is positive that the current proposal brings continuity with a waterways=* for all the water flow. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed features - Voting - Pressurized waterways
2018-01-23 18:17 GMT+01:00 Janko Mihelić : > I would like to add tunnel=headrace to the waterway=drain because that's > how they are called. Just google "headrace tunnel" and this is exactly what > you will get. > This is a great add, thank you. I've missed this terminology, and vote may be stopped to refine the proposal. tunnel=headrace solve pretty big issue I had with tunnel=culvert > > That's why I would like to tag those pipelines as man_made=pipeline + > pipeline=penstock. "Penstock" by itself means that the pipeline is > pressurized, but we can add "pressurized=yes" just to be safe > (waterway=pressurized is a funny tag to me). > It's already done with man_made=pipeline + usage=penstock Given consistency issue I see is free flow headrace comes with waterway=drain + tunnel = headrace but pressurized headrace or penstock with man_made=pipeline only. Why free flow should get a waterway and pressurised none ? I find this confusing. Here what is proposed, separate water from "man made" structures (cut view) : https://imgur.com/a/3KWqZ > Using waterway=drain for underground rivers is not very accurate. I think > a new waterway tag is needed here, because this is a new concept. I suggest > waterway=subterranean_river. And if it has a siphon, add > subterranean_river=syphon. > This is the unsolved issue I mentioned on the image, but proposal wasn't intended to cover it. waterway=drain should be kept on artifical path, I wasn't proposing to use it on natural underground river. waterway=subterranean_river sounds ok for me anyway. > > So, I made an image with my suggestions, changes are bolded and underlined > (I love your images, they are worth a thousand words :) > > https://imgur.com/a/obdNd > Thanks 2018-01-23 18:30 GMT+01:00 Janko Mihelić : >Calling pipelines waterway=pressurized because it would be easier for you to extract it and render it makes this tagging for the renderer. Tags should be as consistent as possible for the mappers, not data consumers. If a mapper sees a pipeline, and you tell him "tag that as waterway=pressurized because then my SQL query can be nice and short" the mapper is going to get annoyed and quit. If it's a pipeline, tag it as a man_made=pipeline, and that's it. Somebody else can tag the type of a pipeline, but nobody is suposed to think about SQL queries when mapping. I gave my personal experience. Prior to do sql queries or really particular stuff, there are models to be done. I'm not only doing rendering but routing also. Tagging isn't currently consistent for mappers at all since they are encouraged to use waterway=canal to tag underground features. I agree there's no point to adapt tagging for sql queries, and it's not what I'm doing. It's all about data model and semantics. François ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Piste:type=connection
Hello, Le 24. 01. 18 à 10:42, Helge Fahrnberger a écrit : > https://wiki.openstreetmap.org/wiki/Proposed_features/Piste:type%3Dconnection > I'd like to start voting you forget to make a request for comment :) end end date look wrong (January <> February) my comment : the definition is strange. "mainly for routing purposes" is not a definition, it's a usecase. Maybe definition should be like : "ways taken by skiers to go from one lift to another or from one lift to another at the beginning of the piste." Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Short-term parking zones
yes, it was. But nobody bothered since the speed was the same in the whole country. I do not know when it was moved to the regional government, even not whether this was before or after the first source:maxspeed was entered in OSM> m. On Tue, Jan 23, 2018 at 10:16 AM, Colin Smale wrote: > Was the speed limit already the responsibility of the regional governments? > Or was there a constitutional change to delegate that power to them? > > If they already had the power, the source:maxspeed value should not have > referred to BE but to Flanders specifically (BE:VL?). > > > > > On 2018-01-23 10:00, Marc Gemis wrote: > > We had this situation last year, when Flanders (northern part of > Belgium) decided to change the speed limit from 90 km/h to 70 km/h. > Brussels and Wallonia kept the default on 90 for rural roads. > Not only was this for a part of the country, but many roads already > had signs for maxspeed 70 or zone 70 before the change. So we had to > change the source:maxspeed as well for all roads, to indicate that it > is now on regional level. > Some roads that were 90 remained 90 after the official changes, but > got (or already had) signs. > > So many more changes were needed than just retagging roads with > source:maxspeed=BE:rural from 90 to 70. > > regards > > m > > On Wed, Jan 17, 2018 at 12:33 PM, Martin Koppenhoefer > wrote: > > 2018-01-16 23:03 GMT+01:00 Kevin Kenny : > > > ...I've never tried to tag any of that sort of regulatory information, but > I can imagine that applying it to all the streets in the town would be both > tedious and unmanageable (the latter because if the town were to change the > ordinance, it would mean updates to many hundreds of highway segments). > > > > > > While I agree it is not the perfect solution, we are trying to deal with > similar provisions (default implicit maxspeed by context) through additional > tags which refer to the legislation. E.g. we add explicit maxspeed tags to > roads inside settlements where the maxspeed is implicit (within the city > limit signs), and add source:maxspeed tags (e.g. value IT:urban in this > case) for the unlikely case, that the law changes, so we can automatically > select all ways with this referrer and change their maxspeed in one go, > without needing to care for signedposted maxspeeds with the same value > (because they should have source:maxspeed=sign or maybe nothing). At least > this is the theory, so far we haven't needed it. > > Even if your regulations are not national or by the state but only in your > county or township, you could add some additional tag that refers to the > ordinance, so if it changes you can change all those cases in one go. > > 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 > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Piste:type=connection
https://wiki.openstreetmap.org/wiki/Proposed_features/Piste:type%3Dconnection Hi, I'd like to start voting on Piste:type=connection, which is needed for walk-overs and other types of connections between lifts. The tag is already in use 102 times in four alpine countries. It is essential for ski routing applications to function. Helge ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
