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 to get visas for 12 African countries to map a single feature. This is impractical: that is, it can't be done by most active OSM mappers, and certainly not by local African mappers who should be in charge of their areas. And the fact is that you won't get a consistent answer. The most pratical source of data for a sea that covers multiple countries would be old, historic maps in the public domain (eg USGS maps of the world). Those old maps won't shown an area for the Gulf of Guinea, they will just have a label near the center. That can help place a node but it won't help you draw an area. Fortunately, 2/3rds of the borders of the Gulf of Guinea are already drawn: that's the coastline. If we have a node place 100 km off the coast, that's enough to know that it should be shown starting at zoom level z7 or z8 or something, and that's all a map-mapper needs to use the information in the node. You don't need an area to make a map. Administrative boundaries: > 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. Coastlines are verifiable locally at every high tide Administrative boundaries are not verifiable in all cases. That's why I've mapped the "Kecematan" (Districts/counties) in Yahukimo as place=county nodes - I know where the district office is located, but there is not useful government map or dataset of the district borders. I'd guess they are located at ridgetops and rivers, but I can't map them until the government releases better data, since I would just be guessing. https://overpass-turbo.eu/s/JZs There is no official source for the boundaries of most seas, straits and bays on the high seas, so we can't rely on 3rd party datasets to map these. The examples I've seen are low-quality and don't match local information. On 6/17/19, Daniel Koć <daniel@koć.pl> wrote: > 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 > _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
