Re: [Tagging] Verifiability of geometry
Daniel, I find this whole conversation pretty off-topic for the tagging forum. Perhaps "Talk" would be more appropriate, since you closed the original discussion on github. 1)Simplification of geometries: > There can be some simplification used (just beware of oversimplification, > especially for bigger objects), but this is always worse than lack of > simplification. Have you every tried to edit an object that was imported badly, with thousands of nodes a few meters apart? I have edited riverbanks that were probably imported by a low-quality automated process, and roads directly imported from GPS traces, and they were very hard to fix (in retrospect I should have just deleted them and redrawn from the new imagery...). That's why the "Fast drawing mode" in JOSM always simplifies objects. Too many unnecessary nodes is worse than too few. It's easy to add nodes to a rough sketch. Removing badly drawn nodes is quite hard. Database objects in OpenStreetMap are abstract representations of map features, not precise copies of a satellite raster image. 2) Straits between curved coastlines: >> straits between concave coasts are one dimensional entities, they have a >> width but they have no length. > I see no support for this claim, so I completely don't agree with it: The example is something like a wide strait between two small, thin islands. Here the strait is just the point at the middle of the channel between the two. You can't make a reasonable line or area out of it, because both islands come to a sharp point, aimed at the strait: https://www.openstreetmap.org/node/3979746373#map=13/34.2944/135.0302 3) Node location verifiability: >> the verifiability of a node location representing a feature exclusively >> depends on if multiple independent placements of the node converge to a >> single location. This is a completely scale independent problem meaning >> variance of different placements can be anywhere from less than a meter to >> hundreds of kilometers. This has no bearing on the principal verifiability. >>>This sentence is very complex, I'm not sure what do you think. Simplified: A node is verifiable if you get a bunch of different local mappers together and ask them all to place a node (or move the node to the correct location). As you add more and more nodes from more people, the average location should become more and more accurate and precise. There will always be a few outliers, but most of the dots will be close enough together. For a small object like an ATM, the nodes will probably be within a few meters of each other, and the average location should be accurate to the nearest meter or even the nearest 10 cm. For a town, the nodes for the place=town will probably be a few 10s or 100's of meters apart, but the average location will probably be within a circle of 10's of meters, since a town is much larger and less precisely defined than an ATM. For a large, vague feature like a sea, the nodes of different mappers will probably be a many kilometers apart. Since the sea is 1000s of times larger than the ATM and much less precisely defined, this is normal, and it's good enough for a computer to guess where to place a label and the size of a label on a map. 4) Gulf of Guinea >When you have 4 different limits of the Gulf of Guinea for example ( >https://commons.wikimedia.org/wiki/File:Limites_du_golfe_de_Guin%C3%A9e-fr.svg >), you will have 4 different central points which don't converge at all (the >distance between the middle of A and D is roughly 1000 km), so using nodes >does not help anything. >At best one can put it in the A area as the common part of all of them, but >this is indirectly choosing A area as proper, which is just hiding the >problem, not getting rid of it. We should choose the center of the smallest area that can be verified to be that feature. For example, we don't label Paris as the geographic center of Ile-de-France. Instead, we place the node near the center of the main business district and historic centre of the city of Paris, since this is where everyone can agree is in Paris. You don't put the node of the place=city San Francisco in the middle of the San Francisco bay, because that's the middle of the metropolitan area, or the middle of the county. You don't even put it in the middle of the land area of the city of San Francisco: you put it near the city hall and the central business district, in the northeast corner of the city on Market Street, because that's the centre of San Francisco by the smallest definition (the historic core). Continued: >The solution would be for example to ask local people from all 12 countries if >they think this part of the coastline belongs to the bay and take their claim >above what others (non-local people) say. At best, it will give you properly >sourced shape. At worst, you may not get the consistent answer - then you >might just simply not map it at all. Ok, I'm a world traveler, but I'm not going
Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel
Good suggestion. I've updated the page. On 6/17/19, Graeme Fitzpatrick wrote: > On Sun, 16 Jun 2019 at 16:39, Joseph Eisenberg > wrote: > >> >> Does this clearly define the difference between a tidal channel and a >> river or stream? >> > > Yep, I reckon that's pretty good :-) > > One minor thing though. > > Your "Example: mapping a tidal channel in mangroves with the JOSM editor" > > It would be helpful to explain what's what that we're looking at eg the > tidal channel is the line of red arrows. > > Thanks > > Graeme > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] lanes = 0
On 16/06/19 22:53, Tobias Zwick wrote: Okay, to wrap this up, I added this title in the wiki and referenced back to this discussion, advising to not use lanes=0/1.5/none to signify no lane markings but instead use something like lane_markings=no. https://wiki.openstreetmap.org/wiki/Key:lanes#No_lane_markings --- Additionally, I noted that after a similar discussion about lanes=1.5 in the German forum in 2017, the wiki page was changed to stress that the lanes-key is for *marked* traffic lanes. The change was announced on the Talk page and the German forum discussion linked there. I did not change the formulation back but only added the outcome of this discussion to that topic on the Talk page because I do not feel legitimated to do that as the 2017 wiki change was also done only after discussion in the community, same as now: https://wiki.openstreetmap.org/wiki/Talk:Key:lanes#No_centerline_-_one_or_two_lanes.3F The community that decided that lanes must be marked in geography small and probably failed to consider the rest of the world. Fine for them to set 'rules' locally but that looks to be causing problems in other parts of the world. I have made comment on the discussion page. https://wiki.openstreetmap.org/wiki/Talk:Key:lanes#Marked_or_unmarked_lanes [1] https://forum.openstreetmap.org/viewtopic.php?pid=627975#p627975 On 15/06/2019 18:55, Martin Koppenhoefer wrote: sent from a phone On 15. Jun 2019, at 01:10, Joseph Eisenberg wrote: This requirement is fine for Europe, but the presence of lane markings is not reliable in all of the world. In developing countries, such as here in Indonesia, the presence of painted lane markings is inconsistent. Often cheap pain is used instead of more durable thermoplastic, so the markings only last a year. After that the road still functions the same, even though the markings are no longer visible. There are also sections of primary or trunk road that are at least 6 or 7 meters wide and freshly painted, but have not yet been marked and may not be for a number of years. I tag these as lanes=2 because the road is clearly wide enough for two lanes. And here in town the main road was recently marked with 2 lanes in each direction, but before it already functioned as 4 lanes because the width was sufficient. While tagging the width is useful, I believe tagging the presence of "de facto" lanes is reasonable in developing countries and places where painted lane markings are not frequently used. This description is a perfect fit for the situation in central Italy as well, not having marked lanes can happen on 2+2 roads for years and for many kilometers. Often there are lane markings for some part of the road while they are missing on others. Generally they are aiming at having lanes, but it isn’t pursued with high priority ;-) I can understand the argument that lanes have to be painted in order to be there, but it isn’t the reality I am observing. We shouldn’t dismiss lane_markings=no as it can solve both cases: no lanes marked but lanes=n is set, and no lanes tag set (confirmation the tag wasn’t forgotten). Cheers, Martin ___ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Verifiability of geometry
W dniu 16.06.2019 o 21:20, Christoph Hormann pisze: > You have stated disagreement with several of these statements but you > have not challenged them in any way by pointing out a logical error or > by arguing why the suggested approach how mappers should decide on how > to map things is of disadvantage to them or to the project as a whole. To have interpretation is not a logical error and I didn't claim that. But lack of objective support makes it just your opinion. It would be really bad if you would contradict yourself, but still it's just a weak point worth showing. Your strait definition for example does not contain logically fallacy, but is just unrelated to reality, as I have shown, which is still OK for philosophy, but bad for mapping, which is about actually representing the world outside. I think this is exactly disadvantage for the project. > I would suggest to you not to concentrate on your spontaneous emotional > reaction You did not see or hear me and you claim some personal statements, which are not only false, but also sound patronizing to me. Please, don't. > of dislike to views like mine that differ from your own but to > consider what objective arguments you have that support your position > and what long term consequences this would have. I have shown you a positive proposition of proper solving the problem of the example object. You have not shown that is logically wrong, so I guess it should enough for you, if you follow your own rules of proving, so here you lack some consistency. But what worries me more is that you just not even commented why this would be a bad thing for reasons other than logic. > You have made clear on a lot of occasions that you reject the concept of > verifiability as a No, I don't - it's just your interpretation. For some reason you claim that changing the type of geometry in the world of geometry into another type of geometry is OK. I wonder if you would change the name into some other name in the database? That's what I call verifiability. And I have not heard something like "verifiability is only for names and existence of the object", the verifiability of geometry was special case to make it clear. If you change the geometry in a subjective way, it does not sound like verifiable for me - you have introduced something virtual instead of real geometry. This rule does not tell anything about perceived expectations of mappers, but also nothing about perceived problems with maintenance. We have areas for admin boundaries and coastlines, which are a burden, but for the sake of verifiability we don't turn them into nodes for example, out of the blue. Even if they are huge and it means fixing them if they break. -- "I see dead people" [Sixth Sense] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] About the diaper key
Hi, On Wed, 12 Jun 2019 16:14:59 +0200, Valor Naram wrote: > the proposal at > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table has > been accepted now and I can start with the post-vote process and > creating a wiki page. The property Key:changing_table success the > Key:diaper for now but we or at least I have to deal with the question > "What's going on with the diaper key". The answer seems clear: > Key:diaper is now superseded by Key:changing_table. While it's the part > you CAN definetly answer with ease. The second part properly not. "What > do we do with the POIs having the Key:diaper?" > > I am very excited about hearing your ideas since some of you noted that > just replacing the diaper key and its values with the key and the values > of the new key can be problematic. I suggest finding data consumers (people/apps/sites/software which uses the existing `diaper` tag), and talking to them about supporting the new `changing_table` tag. Likewise talk to data contributors (editing software) and talk them into supporting your new scheme. I really don't think a mechanical edit to change all is a good idea. You can't rely on all data consumers to read all lists & wiki pages, and you risk a data consumer re-adding the `diaper` tag. If no-one's using the `diaper` tag, then why not make or encourage data consumers to support it? Rory ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Verifiability of geometry
On Sunday 16 June 2019, Daniel Koc4� wrote: > > Christoph (imagico) has proposed there a set of example rules that he > believes are self evident and invited to challenge them if someone > disagrees, so here I am: Not quite - this is just a collection of statements regarding matters where you claim i did not provide answers to or where you repeatedly bring up arguments based on assumptions that have been refuted in the past already (like the persistent idea that any two-dimensional entity should best be modeled in OSM with a polygon). It is neither meant to be an exhaustive framework of principles nor are they necessarily useful as practical rules. All of these are not new statements - they are not literal quotes but i have made them in previous discussions in similar form (here, on the wiki, on github or elsewhere). You have stated disagreement with several of these statements but you have not challenged them in any way by pointing out a logical error or by arguing why the suggested approach how mappers should decide on how to map things is of disadvantage to them or to the project as a whole. With challenging my statements i mean providing evidence for them to be false. I would suggest to you not to concentrate on your spontaneous emotional reaction of dislike to views like mine that differ from your own but to consider what objective arguments you have that support your position and what long term consequences this would have. You have made clear on a lot of occasions that you reject the concept of verifiability as a guiding principle for mapping decisions but so far the only reason for this you have ever given is essentially because it is inconvenient and it prevents the addition of data to OSM you would like to see added. Given that the reasons why we have and should keep the verifiability principle have been discussed really extensively this all seems frankly a bit opportunistic. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel
On Sun, 16 Jun 2019 at 16:39, Joseph Eisenberg wrote: > > Does this clearly define the difference between a tidal channel and a > river or stream? > Yep, I reckon that's pretty good :-) One minor thing though. Your "Example: mapping a tidal channel in mangroves with the JOSM editor" It would be helpful to explain what's what that we're looking at eg the tidal channel is the line of red arrows. Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Verifiability of geometry
Hi, There are still some problems with verifiability of objects geometry. This has been discussed lately here: https://github.com/gravitystorm/openstreetmap-carto/pull/3750 but we came to the conclusion that this is not the best place to go with fundamental problems, so I come here to talk about tagging strategies. Christoph (imagico) has proposed there a set of example rules that he believes are self evident and invited to challenge them if someone disagrees, so here I am: * polygons are a way to geometrically define a two dimensional entity through (and only through) an explicit delineation of its one dimensional boundaries. I agree with that. That's why area mapping for bays is good as long as you have a source for this. This is what we do with admin borders - we get the nodes that we know and simply link them. Or we use some data from authorities. No matter what source do you use, there can be disagreement (look at admin borders problems which are not solved to this moment, yet we don't simplify admin objects into nodes or lines because of that). * for the decision what kind of feature to use to represent a certain real world feature in the OSM database mappers should put mapping and data maintenance efficiency above perceived desires of data users. The main criterion should be how to most efficiently represent verifiable information on the feature in question without storing either redundant or non-verifiable data. Written rule does not support this interpretation, it's short and clear. Data maintenace is not a rule, is not mentioned there even as an excuse or exception and of course is not higher level rule than verifiability. On the other hand people commonly use nodes or lines for representing areas. There is simply a clash between written rules and the common usage. It's the open question how should it be solved. * there is no principal connection between the nature of a real world object and how it can or should be represented in OSM above the mapping efficiency criterion previously mentioned. I don't agree here. There can be some simplification used (just beware of oversimplification, especially for bigger objects), but this is always worse than lack of simplification. * straits between concave coasts are one dimensional entities, they have a width but they have no length. I see no support for this claim, so I completely don't agree with it: - "Most commonly it is a channel of water" (Wikipedia, strait) - channel has length and width - "The shortest distance across the strait, 33.3 kilometres" (Wikipedia, Strait of Dover) - the mentioned thing is only a part of the strait, not the whole entity - "A narrow area of water surrounded by land on two sides and by water on two other sides." (description on the OSM wiki) * the verifiability of a node location representing a feature exclusively depends on if multiple independent placements of the node converge to a single location. This is a completely scale independent problem meaning variance of different placements can be anywhere from less than a meter to hundreds of kilometers. This has no bearing on the principal verifiability. This sentence is very complex, I'm not sure what do you think. When you have 4 different limits of the Gulf of Guinea for example ( https://commons.wikimedia.org/wiki/File:Limites_du_golfe_de_Guin%C3%A9e-fr.svg ), you will have 4 different central points which don't converge at all (the distance between the middle of A and D is roughly 1000 km), so using nodes does not help anything. At best one can put it in the A area as the common part of all of them, but this is indirectly choosing A area as proper, which is just hiding the problem, not getting rid of it. The solution would be for example to ask local people from all 12 countries if they think this part of the coastline belongs to the bay and take their claim above what others (non-local people) say. At best, it will give you properly sourced shape. At worst, you may not get the consistent answer - then you might just simply not map it at all. -- "I see dead people" [Sixth Sense] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] lanes = 0
In Spain is easy: when there is no marks = lanes=1 The lack of the mark lanes is the reason why when a Spaniard drives by Rome thinks Italian people are crazy, because they overtake you in the same big lane, but ONLY one lane (lane without marks). One lane= one car. lane with no marks is =1 (driver's school book says that) so lane=0 would be impossible and ununderstable for a Spaniard wherever in the World. Cheers Yopaseopor On Sat, Jun 15, 2019 at 6:59 PM Martin Koppenhoefer wrote: > > > sent from a phone > > > On 15. Jun 2019, at 01:10, Joseph Eisenberg > wrote: > > > > This requirement is fine for Europe, but the presence of lane markings > > is not reliable in all of the world. > > > > In developing countries, such as here in Indonesia, the presence of > > painted lane markings is inconsistent. Often cheap pain is used > > instead of more durable thermoplastic, so the markings only last a > > year. After that the road still functions the same, even though the > > markings are no longer visible. > > > > There are also sections of primary or trunk road that are at least 6 > > or 7 meters wide and freshly painted, but have not yet been marked and > > may not be for a number of years. I tag these as lanes=2 because the > > road is clearly wide enough for two lanes. > > > > And here in town the main road was recently marked with 2 lanes in > > each direction, but before it already functioned as 4 lanes because > > the width was sufficient. > > > > While tagging the width is useful, I believe tagging the presence of > > "de facto" lanes is reasonable in developing countries and places > > where painted lane markings are not frequently used. > > > > This description is a perfect fit for the situation in central Italy as > well, not having marked lanes can happen on 2+2 roads for years and for > many kilometers. Often there are lane markings for some part of the road > while they are missing on others. Generally they are aiming at having > lanes, but it isn’t pursued with high priority ;-) > I can understand the argument that lanes have to be painted in order to be > there, but it isn’t the reality I am observing. > > We shouldn’t dismiss lane_markings=no as it can solve both cases: no lanes > marked but lanes=n is set, and no lanes tag set (confirmation the tag > wasn’t forgotten). > > 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] lanes = 0
Okay, to wrap this up, I added this title in the wiki and referenced back to this discussion, advising to not use lanes=0/1.5/none to signify no lane markings but instead use something like lane_markings=no. https://wiki.openstreetmap.org/wiki/Key:lanes#No_lane_markings --- Additionally, I noted that after a similar discussion about lanes=1.5 in the German forum in 2017, the wiki page was changed to stress that the lanes-key is for *marked* traffic lanes. The change was announced on the Talk page and the German forum discussion linked there. I did not change the formulation back but only added the outcome of this discussion to that topic on the Talk page because I do not feel legitimated to do that as the 2017 wiki change was also done only after discussion in the community, same as now: https://wiki.openstreetmap.org/wiki/Talk:Key:lanes#No_centerline_-_one_or_two_lanes.3F [1] https://forum.openstreetmap.org/viewtopic.php?pid=627975#p627975 On 15/06/2019 18:55, Martin Koppenhoefer wrote: > > > sent from a phone > >> On 15. Jun 2019, at 01:10, Joseph Eisenberg >> wrote: >> >> This requirement is fine for Europe, but the presence of lane markings >> is not reliable in all of the world. >> >> In developing countries, such as here in Indonesia, the presence of >> painted lane markings is inconsistent. Often cheap pain is used >> instead of more durable thermoplastic, so the markings only last a >> year. After that the road still functions the same, even though the >> markings are no longer visible. >> >> There are also sections of primary or trunk road that are at least 6 >> or 7 meters wide and freshly painted, but have not yet been marked and >> may not be for a number of years. I tag these as lanes=2 because the >> road is clearly wide enough for two lanes. >> >> And here in town the main road was recently marked with 2 lanes in >> each direction, but before it already functioned as 4 lanes because >> the width was sufficient. >> >> While tagging the width is useful, I believe tagging the presence of >> "de facto" lanes is reasonable in developing countries and places >> where painted lane markings are not frequently used. > > > > This description is a perfect fit for the situation in central Italy as well, > not having marked lanes can happen on 2+2 roads for years and for many > kilometers. Often there are lane markings for some part of the road while > they are missing on others. Generally they are aiming at having lanes, but it > isn’t pursued with high priority ;-) > I can understand the argument that lanes have to be painted in order to be > there, but it isn’t the reality I am observing. > > We shouldn’t dismiss lane_markings=no as it can solve both cases: no lanes > marked but lanes=n is set, and no lanes tag set (confirmation the tag wasn’t > forgotten). > > 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] Marking legal BBQ locations
Thanks everyone, particularly John for a very detailed explanation! A set-up like that is a new one to me - here we usually have either electric or gas BBQs in urban parks, or you BYO; & then have prepared concrete / brick wood-burning BBQs in National Parks & similar, where you usually have to BYO wood! As I say, an established spot that you put your own wood-burner in is a version I haven't seen before, & I can see that =firepit wouldn't really work. Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel
I would appreciate help with the description and definition for tidal channels: aka tidal creeks, sloughs, pills, usually located in salt marshes, tidal flats or mangroves. Right now the short description is: "A natural intertidal waterway in mangroves, salt marshes and tidal flats with water flow in the direction of the tide" And the longer definition: "Use waterway=tidal_channel for a natural tidal waterway within the coastal marine environment with bi-directional flow of salty water which depends on the tides. Such channels form along protected coasts with limited wave action and a gradual slope, usually within tidal mud flats, salt marshes or mangroves. These channels can be distinguished from rivers due to the higher salinity levels and because the flow of water away from the sea at high tide is equal to the flow of water towards the sea at low tide." Does this clearly define the difference between a tidal channel and a river or stream? Please comment on the waterway=tidal_channel proposal or here: https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel I've added more photos and examples there too. On 6/6/19, Joseph Eisenberg wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel > > As discussed back in September 2018, we need another tag for tidal > channels, also known as "pills" or "tidal creeks" > > These are natural tidal waterways within the coastal, environment with > bi-directional flow of salt water, so they are not a stream or river > estuary. They should be located outside of the coastline. > > Such channels commonly form along protected coasts with limited wave > action and a gradual slope, usually within tidal flats, salt marshes > or mangroves. > > Examples: > 1) Wöhrdener Loch - tidal channel in mud flats: > https://www.openstreetmap.org/way/401730966 > > 2) Barbara Channel - channel in mud flats: > https://www.openstreetmap.org/way/694300595 > > 3) Cabbage Creek - tidal creek in salt marsh: > https://www.openstreetmap.org/way/121698431 > > 4) Tidal channel in mangroves: > https://www.openstreetmap.org/way/694868357 > > Image: > https://wiki.openstreetmap.org/wiki/File:Mangroves-tidal-channels-josm-example-5km-4km-papua-indonesia.png > > See the whole proposal with more images and explanation: > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel > > Please comment here or on the talk page: > https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tag:waterway%3Dtidal_channel > > - Joseph Eisenberg > > > PS: Sorry, Simon - last one this month - but I did map several hundred > of these myself - lots of mangroves here. > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
