Re: [Tagging] Another multipolygon question
On 21/10/18 12:24, Kevin Kenny wrote: Works great, right up until you need to maintain it. So, you've got your "natural=wood" multipolygon sharing a way with an adjoining "natural=scrub". And then, some inconsiderate developer bulldozes his way across the boundary and puts up a housing development. Now what do you do? You can't unglue the boundary and shrink the two affected areas to make room for the "landuse=residential" because there's only one way. The only option I've found is to remove the affected section of boundary from one of the multipolygons, move it to the new location, create a new boundary way for the other multipolygon in the proper place and add it, create a new multipolygon for the development and add the relevant boundary ways to it, and then confirm that you haven't broken any of the multipolygons involved. It's painful enough that it's usually faster and easier just to delete everything and re-create them from scratch as ordinary closed ways. I actually do edit those things pretty routinely. It involves redrawing only for the added ways. Draw the new closed polygon representing the landuse=residential. Make it a multipolygon immediately. Insert nodes at the intersections of this closed way with the existing ways (if you didn't draw it that way to start with). Split the old and new ways on the nodes. (Splitting is safe - they're multipolygons already.) JOSM has an 'add nodes at intersections' feature that helps with this. Edit each of the old multipolygons to replace their old boundaries with the new ones. That's just 'remove the old ways, insert the new ones' in the relation editor. Finally, delete any ways that are now unused. I can do this *lots* faster than I can redraw an irregular boundary, at least in JOSM. (I'm not skilled enough with iD to comment. it wasn't much harder in Meerkartor when I tried it.) An area of sand I introduced .. between a natural coastline, a tree area and a water area... Relation: 8718211. Using JOSM. Yes the coastline was already a relation, as was the tree area.. I don't remember what the water areas was.. probably a relation too. Most, if not all, the coastlines I deal with are relations. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Another multipolygon question
> > Works great, right up until you need to maintain it. So, you've got > your "natural=wood" multipolygon sharing a way with an adjoining > "natural=scrub". And then, some inconsiderate developer bulldozes his > way across the boundary and puts up a housing development. Now what do > you do? You can't unglue the boundary and shrink the two affected > areas to make room for the "landuse=residential" because there's only > one way. > > The only option I've found is to remove the affected section of > boundary from one of the multipolygons, move it to the new location, > create a new boundary way for the other multipolygon in the proper > place and add it, create a new multipolygon for the development and add > the relevant boundary ways to it, and then confirm that you haven't > broken any of the multipolygons involved. It's painful enough that > it's usually faster and easier just to delete everything and re-create > them from scratch as ordinary closed ways. > I actually do edit those things pretty routinely. It involves redrawing only for the added ways. Draw the new closed polygon representing the landuse=residential. Make it a multipolygon immediately. Insert nodes at the intersections of this closed way with the existing ways (if you didn't draw it that way to start with). Split the old and new ways on the nodes. (Splitting is safe - they're multipolygons already.) JOSM has an 'add nodes at intersections' feature that helps with this. Edit each of the old multipolygons to replace their old boundaries with the new ones. That's just 'remove the old ways, insert the new ones' in the relation editor. Finally, delete any ways that are now unused. I can do this *lots* faster than I can redraw an irregular boundary, at least in JOSM. (I'm not skilled enough with iD to comment. it wasn't much harder in Meerkartor when I tried it.) > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Another multipolygon question
Wow, the West Point and the Hudson Highlands State Park multipolygons are impressive and yes, I see how using multipolygons has made it simpler. Except if, as Mark points out, one of the boundaries changes and then it's going to be an awful mess to fix. In my particular use case, it's highly unlikely that developers will move anything seeing as most of my Alaska work is in country so wild I'll never see any of it in my lifetime. But I can certainly appreciate the difficulty in changing a beast like that. On some of the larger islands where there are areas without trees I'll use the coastline way as a border by clicking along it and using (F)ollow in JOSM thus using those nodes for two purposes. When a clearing or beach occurs I simply move off the coastline, trace around the clear area, and then rejoin the coastline way. Then later, if adjustments need to be made I can simply unglue the wood area nodes where I need to. As for Warin's comment, I'm not sure it makes any difference as to which of natural=wood or natural=coastline gets tagged at top level. Unless, of course, the coastline is already a multipolygon. Opinions? On Sun, Oct 21, 2018 at 2:12 AM Mark Wagner wrote: > On Sat, 20 Oct 2018 09:49:57 -0500 > Kevin Kenny wrote: > > > Not only legitimate, but recommended! > > > > If you haven't stumbled on it yet, another useful procedure is to map > > areas of landuse use or landcover by drawing each border only once, > > and having each area be a multipolygon with the shared border way as > > a member. With that approach there's no need to retrace an irregular > > boundary. You just add it to the multipolygon on either side. > > Works great, right up until you need to maintain it. So, you've got > your "natural=wood" multipolygon sharing a way with an adjoining > "natural=scrub". And then, some inconsiderate developer bulldozes his > way across the boundary and puts up a housing development. Now what do > you do? You can't unglue the boundary and shrink the two affected > areas to make room for the "landuse=residential" because there's only > one way. > > The only option I've found is to remove the affected section of > boundary from one of the multipolygons, move it to the new location, > create a new boundary way for the other multipolygon in the proper > place and add it, create a new multipolygon for the development and add > the relevant boundary ways to it, and then confirm that you haven't > broken any of the multipolygons involved. It's painful enough that > it's usually faster and easier just to delete everything and re-create > them from scratch as ordinary closed ways. > > -- > Mark > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Default Language Format
Excuse me if I didn't make myself clear, English is not my native language. In OSM the name of a place is usually, but not always the name on the sign. If the sign only had space for 5 characters, it will in many cases contain the short_name, not the name. In some cases, a venue would erect multiple signs, some larger than others, some ever containing a strapline=* as well. The most reliable method I've found to determine the name of an entity was from the menu up to now, then comes the registry, the website, the receipt and only then the signs. Some places don't even have a sign up, others didn't have the money to replace the sign that advertised old_name=* and hence left that up. The more names I come across for a given venue the more fun it is to unify all of those to a handful of name keys! So when surveying, I never solely enter name tags from signs without going inside the amenity and asking around and I recommend this practice to other mappers as well. Maybe I don't follow fully, but you should definitely not put the name of the business into operator=* in most cases, please check the wiki what this key is for: https://wiki.openstreetmap.org/wiki/Key:operator Back to the previous example, we have a database that lists both the operator and the full official name of a venue. It is difficult to mix up the operator and the venue name, as they rarely resemble each other. Establishing a company around here has lots of overheads, so people do this as rarely as possible. It is the norm that during the life cycle of a company, it opens, closes and renames/rebrands its shops or even moves onto other domains. Companies are also renamed and retargeted a lot, probably up to a dozen times on average. Companies purchase brands from each other, etc. So in the above example, we have: operator=AmRest Vendéglátó Kft. name=KFC Gyorsétterem short_name=KFC (although this is already present in brand=* as mentioned above, so I omit this) For example, it's common for people to refer to pubs with short_names. Also, most pubs around here are operated by private individuals (entrepreneurs), a few by legal entities/companies. So I'm sure nobody would mix up operator="John Smith" with name="The Drunken Clam" or short_name="The Clam". On Sat, Oct 20, 2018 at 11:26 AM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 19. Oct 2018, at 20:14, bkil wrote: > > > > So this should usually be very close to the official name. In a few > > cases, I have seen that the printer produced old_name. In other cases, > > everyone knows the place by its short_name and it is the one usually > > advertised on signs, though the menu, website and receipt usually all > > include the full name. > > > in OSM the name of the place is usually the one used by the people and on > the sign, the name of the business is tagged as operator. > The requirements for receipts differ in national legislation. From the > receipts I used in Germany and Italy, name as we use in OSM was often > there, but if the receipt has only the minimum required information, there > is just the operator name and address (date, goods, price, tax etc), the > vat identification number is mandatory in Italy but not in Germany (for > receipts <250eur), although it will usually be there in Germany as well. > What the law refers to as “name” is actually the operator. > > 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] How to document my new feature?
Yes, it's a good idea to creating pages for all the keys and subkeys to aid taginfo visibility. If you use redirects, the Wiki tab will link be populated, like so: https://taginfo.openstreetmap.org/keys/contact%3Aphone#wiki If you use use non-redirected pages, the description field will also be populated, as in: https://taginfo.openstreetmap.org/tags/internet_access=wlan#wiki Although creating a separate page per tag value seems a bit excessive, so I'd stop at the (sub)key part. On Sat, Oct 20, 2018 at 1:22 PM marc marc wrote: > Le 20. 10. 18 à 13:08, Daniele Santini a écrit : > > - edit the existing emergency=assembly_point wiki page adding the new > > tags (like has been done with name:=* inside the name=* page) > > yes, at least > > > - create a single new wiki page to describe them all > > "Key:assembly_point > assembly_point in assembly_point:fire=yes is not a key. > it's a namespace > > > - create a new wiki page for each new tag > > why not but due the fact that each page 'll be very light, > a redirect to emergency=assembly_point seems imho to be enought > > Regards, > Marc > ___ > 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] Another multipolygon question
On Sat, 20 Oct 2018 09:49:57 -0500 Kevin Kenny wrote: > Not only legitimate, but recommended! > > If you haven't stumbled on it yet, another useful procedure is to map > areas of landuse use or landcover by drawing each border only once, > and having each area be a multipolygon with the shared border way as > a member. With that approach there's no need to retrace an irregular > boundary. You just add it to the multipolygon on either side. Works great, right up until you need to maintain it. So, you've got your "natural=wood" multipolygon sharing a way with an adjoining "natural=scrub". And then, some inconsiderate developer bulldozes his way across the boundary and puts up a housing development. Now what do you do? You can't unglue the boundary and shrink the two affected areas to make room for the "landuse=residential" because there's only one way. The only option I've found is to remove the affected section of boundary from one of the multipolygons, move it to the new location, create a new boundary way for the other multipolygon in the proper place and add it, create a new multipolygon for the development and add the relevant boundary ways to it, and then confirm that you haven't broken any of the multipolygons involved. It's painful enough that it's usually faster and easier just to delete everything and re-create them from scratch as ordinary closed ways. -- Mark ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Another multipolygon question
It conflicts with natural=coastline On Sat, Oct 20, 2018, 10:36 marc marc wrote: > > create a single-member multipolygon from the coastline way > > and then tag the resultant relation with natural=wood > > I often put the natural=wood on the inner way itself > it's not working for some apps/render style ? > ___ > 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] Another multipolygon question
> create a single-member multipolygon from the coastline way > and then tag the resultant relation with natural=wood I often put the natural=wood on the inner way itself it's not working for some apps/render style ? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Another multipolygon question
Not only legitimate, but recommended! If you haven't stumbled on it yet, another useful procedure is to map areas of landuse use or landcover by drawing each border only once, and having each area be a multipolygon with the shared border way as a member. With that approach there's no need to retrace an irregular boundary. You just add it to the multipolygon on either side. For an example, look at West Point. https://www.openstreetmap.org/relation/175474 and how the shared ways with the parks, cemeteries, golf courses, and so on are handled. It means that even simple areas like https://www.openstreetmap.org/relation/7084917 become multipolygons, but it ensures that the boundaries all stay consistent, because you need to map each one only once. On Sat, Oct 20, 2018, 06:22 Martin Koppenhoefer wrote: > > > sent from a phone > > > On 20. Oct 2018, at 11:38, Dave Swarthout > wrote: > > > > But yesterday I tried something new, new for me anyway, and that was to > create a single-member multipolygon from the coastline way and then tag the > resultant relation with natural=wood in order to reduce the number of nodes > used. I was pleased that JOSM didn't complain and that the island seemed to > render okay but I'm not sure this is a legitimate procedure > > > I also do this, for example if there’s a fence but I also want to tag the > area it delimits. Or for buildings and things that are there, in some cases. > > > 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] Another multipolygon question
sent from a phone > On 20. Oct 2018, at 11:38, Dave Swarthout wrote: > > But yesterday I tried something new, new for me anyway, and that was to > create a single-member multipolygon from the coastline way and then tag the > resultant relation with natural=wood in order to reduce the number of nodes > used. I was pleased that JOSM didn't complain and that the island seemed to > render okay but I'm not sure this is a legitimate procedure I also do this, for example if there’s a fence but I also want to tag the area it delimits. Or for buildings and things that are there, in some cases. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to document my new feature?
Le 20. 10. 18 à 13:08, Daniele Santini a écrit : > - edit the existing emergency=assembly_point wiki page adding the new > tags (like has been done with name:=* inside the name=* page) yes, at least > - create a single new wiki page to describe them all > "Key:assembly_point assembly_point in assembly_point:fire=yes is not a key. it's a namespace > - create a new wiki page for each new tag why not but due the fact that each page 'll be very light, a redirect to emergency=assembly_point seems imho to be enought Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to document my new feature?
Hi, my proposal [1] has just been approved and I am trying to do the cleanup as requested by the proposal process. However I am stuck because I have a doubt on how to create the wiki page for the new feature. The approved proposal introduces a series of new tags under the assembly_point namespace (like assembly_point:fire=*, assembly_point:tsunami=*, etc). I have 3 options: - edit the existing emergency=assembly_point wiki page adding the new tags (like has been done with name:=* inside the name=* page) - create a single new wiki page to describe them all - create a new wiki page for each new tag (like has been done with addr:=* inside the Key:addr page and in a page for each tag) What should I do? If i choose the second option would the name "Key:assembly_point" be ok? [1] https://wiki.openstreetmap.org/wiki/Proposed_features/assembly_point:purpose -- Daniele Santini http://www.dsantini.it ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Another multipolygon question
Another situation that occurs quite frequently in my mapping (in Alaska especially), is when an island defined by natural=coastline is also covered right to the water with natural=wood. Usually, I duplicate the coastline, shrink it a bit, and then tag it with natural=wood. But yesterday I tried something new, new for me anyway, and that was to create a single-member multipolygon from the coastline way and then tag the resultant relation with natural=wood in order to reduce the number of nodes used. I was pleased that JOSM didn't complain and that the island seemed to render okay but I'm not sure this is a legitimate procedure. , The island is at 58.56588, -152.59579 and the relation ID=8828482 What do you think is the best approach to handle this situation? Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Default Language Format
sent from a phone > On 19. Oct 2018, at 20:14, bkil wrote: > > So this should usually be very close to the official name. In a few > cases, I have seen that the printer produced old_name. In other cases, > everyone knows the place by its short_name and it is the one usually > advertised on signs, though the menu, website and receipt usually all > include the full name. in OSM the name of the place is usually the one used by the people and on the sign, the name of the business is tagged as operator. The requirements for receipts differ in national legislation. From the receipts I used in Germany and Italy, name as we use in OSM was often there, but if the receipt has only the minimum required information, there is just the operator name and address (date, goods, price, tax etc), the vat identification number is mandatory in Italy but not in Germany (for receipts <250eur), although it will usually be there in Germany as well. What the law refers to as “name” is actually the operator. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power=cable for low voltage lines?
Le sam. 20 oct. 2018 à 04:07, Greg Troxel a écrit : > If so, I agree, but it's been explained that this fight happened a while > ago and what we have now is the outcome. > Not exactly. I began to contribute to OSM in 2012. People already get used to line/minor_line/cable. All those tags were well established and the only pro argument was "there are too much of them, we won't change" and we are stuck in the statu quo until now We all agree on necessarily classification, but the only argument in favor of line/minor_line is they are too used to change. IEC do have distinction between line and cable but line sounds to be the most general term with or without insulation Line: http://www.electropedia.org/iev/iev.nsf/display?openform=151-12-27 Cable: http://www.electropedia.org/iev/iev.nsf/display?openform=151-12-38 No entry for any "minor" or "major" line It seems in this case the OSM way is just to use power=line, don't > worry, and let others fix it up if necessary. > That would make sense, if and only if everyone agree on definitions. They are required to be objective. In practice this can lead to editing wars since current tags are sometimes related to "small" or "big" size distinctions. All the best François > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
