Talk:Tag:place=sea
Jump to navigation
Jump to search
Why not simplified area/polygon?
Can someone explain why the seas cannot/should not be mapped as (simplified) polygons? This would make it possible to e.g. tell approximately how large the sea is, render the name on maps covering just a part of the sea, and to scale the name depending on the size of the sea. --Anderfo (talk) 10:02, 20 December 2017 (UTC)
- Seas should not be mapped as simplified polygons because the geometry is not verifiable when it does not follow the coastline. It is also a bad idea to attempt to map seas at multipolygon relations, because most seas would require hundreds of members and have many holes due to each small island within the sea. This would be difficult to maintain. While the coastline is a correct limit for the sea, most seas have a long border with the open ocean or a larger sea which is not verifiable. For these reasons, it's best to map a sea with a node. --Jeisenbe (talk) 07:44, 23 March 2019 (UTC)
- I understand what you are saying, but I don't agree that simplified polygons would be useless; I think they would be much better than nodes for several reasons (as described above). Does really the approximate "border" of a place need to be verifiable, and is it really useless to try to estimate the size of a sea?
- To turn the seas into multipolygons and insert holes for each island would be a bad idea, as you write, since islands are actually in the sea and not outside of it (and of course, 10,000 islands/islets/holes in the Mediterranean Sea would turn it into a too big relation). But why would a sea need a "hole" in it at all, if the main purpose of it was to know approximately the size and position of this sea, as well as the name and other relevant information? (on the other hand, a single node does not indicate anything else than the approximate position of something of completely unknown size...)
- I think that the size of the feature is useful information for knowing e.g. how large/important the name of the feature should be on the rendered map. A place=sea does not have to be colored or anything like that (which would cover/hide islands), it is mainly for specifying a name and other info about a sea, in my opinion. And it would make it possible to figure out automatically e.g. which sea an island belongs to or which seas a strait is linking. And it would make it possible to render the name of the sea even on a map covering just part of the sea and where the single node would have been outside of that map.
- Are all these benefits minor to the (potential) drawback of not having verifiable borders of the simplified polygon? --Anderfo (talk) 19:55, 24 March 2019 (UTC)
- Simplified polygons are certainly useful, but to be included in OSM a feature needs to be "real and current." Many of the coastlines in OSM, including fully enclosed seas like the Caspian and Black Sea, were initial drawn very roughly from poor-quality Satellite imagery, but now most have been greatly improved by using good aerial imagery or even survey with GPS by walking along the high-water line. That's the good-quality data that OSM strives to achieve. We already have these good coastline geometries, so these should be used to determine the limits of seas when necessary, not a simplified coastline.
- While islands are sometimes thought of being included in a sea, where would one draw the line? Would Madagascar be included in a polygon for the Indian ocean? Would Cyprus be included in the Med. Sea polygon? The seas are marine water bodies, and should not include the islands, especially if one wishes to know the surface area of the water body. That's why the correct coastline needs to be used. Unfortunately, this means that multipolygons for large seas like the Caribbean will be impossible to manage with normal consumer computers and the normal tools like the OSM.org website and ID editor. Even mid-sized seas like the Aegean are very difficult to load on my laptop.
- The size of a feature is certainly useful information. I would personally be in favor of adding a tag to sea nodes which would show the area; eg surface_area=<number in square kilometers>, although for rendering an ordinary Web map in Mercator projection, the east-west extent of the sea is actually more important for proper labeling.
- While there are certainly benefits to having complete polygons (and simplified polygons) for seas, these features should be calculated from the sea nodes plus the existing coastlines. Currently the coastline are just lines, and to use them they have to be processed into polygons, which are available on https://osmdata.openstreetmap.de/ - I'm not a software programmer, but apparently it's simple enough to create polygons for each sea. (See http://github.com/gravitystorm/openstreetmap-carto/issues/2278) I've now requested that such data be made available from the same source. (https://github.com/fossgis/osmdata/issues/3) This will allow mappers to just place nodes, and then the computers can do all the work of making polygons for high zoom levels and simplified polygons for rendering low zoom levels. --Jeisenbe (talk) 00:13, 25 March 2019 (UTC)
- Note that I'm not suggesting to replace the coastline by a simplified line or replacing the water body by simplified polygons; I am just proposing to use simplified polygons (or, potentially, simple multipolygons) for the place=sea feature. The area calculation will just be approximate and would include islands, but that is a small drawback (in my opinion) compared to restricting the use to a single node. Maybe a tag can be used to define the area more precisely, as you suggest, even on simplified polygons... For small seas, the coastline may be part of the multipolygon, while for large seas the lines would need to be simplified and only approximately follow the coastline.
- Remember that a sea node placement is also not "verifiable". The same goes for the "border" of a mountain range, a forest or a valley, it is often impossible to define them in a verifiable manner, but still we would prefer to have names also on such features on a map. The value of the map is reduced when those names are inexistent, I believe.--Anderfo (talk) 09:23, 25 March 2019 (UTC)
- The exact sea node placement is not verifiable, but it is possible to say if the node is in the sea. The border towards the open ocean is the non-verifiable part which is questionable to map. The coastline is verifiable within a certain range of error due to tides. But using a highly simplified copy of the coastline to map the sea is adding a non-verifiable line into the database.
- We do not map the borders of mountain ranges or valleys for this reason. Most mountains are mapped as a node on the highest peak, and ranges can be mapped by a way that follows the crest of the ridge. The problem is deciding where the mountain ends on the low side. The same problem exists with valleys; how far up the hill do they extend? That's why it's better to map such features as a node in the center, or a line along the (verifiable) high or low ground. --Jeisenbe (talk) 12:02, 25 March 2019 (UTC)
Image
@Jeisenbe: Thanks for improving the image. So far i remember i did just copy the image from the "Q" data-item page. And i assume the data-item synced it from the PL-page. So if you like you might also update the image on the PL-page, see also here for overview. Regards --MalgiK (talk) 02:36, 6 November 2020 (UTC)