Talk:Tag:natural=coastline

From OpenStreetMap Wiki
Jump to: navigation, search

Discuss Tag:natural=coastline here


Bulk imports / data size problems

"Deprecation Discussion" was moved to Talk:Tag:natural=coastline deprecation

Sorry for the confusion. I've archived off deprecation discussion because it seems any talk of deprecation and purging was actually dead and gone a long time ago. The concensus is not deprecated. Everyone I've spoken to seems to concurr. So just now I've stated that more clearly on the information here.

All that remains is to clarify recommendations regarding bulk imports (which does relate to the pros and cons listed on Tag:natural=coastline deprecation) People will consider the possibility of a group effort to get it all imported, unless we are clear about recommendation against that course of action due to data size problems. Do we have data size problems? What's the plan?

-- Harry Wood 10:33, 14 September 2007 (BST)

I think the warning against bulk imports is more of a general thing: Anything, be that coastline or something else, which significantly increases the volume of data we currently have (e.g. doubles the size of the planet file) should be discussed on the lists before. If you just do, say, Iceland, that's not a big deal. But if you intend to do the whole of Africa then it might be sensible to first think about how much data this is going to be, how long the import is going to take, whether it makes sense to assign a special API thread to it, etc. etc. etc. - I guess a good rule of thumb is: as long as you can upload your stuff with JOSM just do it, but when you have so much data that you start batch-uploading because JOSM becomes unwieldy, do announce your ideas on the list before and see if somebody shouts. --Frederik Ramm 12:06, 24 September 2007 (BST)
Bulk import could also be done for elevation data via Srtm2Osm, but i guess we all agree that this would add far too much data to be handled by current infrastructure. But having all the data in one place does have some benefit of being able to cross reference it, better see the context while editing data and also to allow editing of such "static" data (coastlines, elevations) when it changes. Editors should probably load such layers only on demand and in read-only mode by default. How about layer=coastline and layer=elevation and an option in API to not serve those layers unless specifically requested? --Stefanb 13:51, 14 October 2007 (BST)

How to correctly tag

I am working on a city which lies at the coast of the Baltic Sea. How do I correctly tag the coastline, so that the water is rendered blue? I tried "natural=coastline". This displays a blue line, but the water does not get filled. I remember seeing some renderings, where the water of the coast is really blue. How was that done?
RalfZ 12:19, 4 November 2006 (UTC)

When to use to natural=water ?

Q: I'm still unclear how coastline would be used in contrast to filled "natural=water" areas. Anybody cares to clarify? Spaetz 08:57, 21 March 2007

Well natural=water is for lakes. So the only question is... Do you switch to tagging as coastline if it's a really huge lake? I dunno. I guess I would say not, although... do the renderers require a natural=water lake to be a closed way? (maybe awkward for very large lakes)
Another tricky question is, how does natural=coastline relate to waterway=river and waterway=riverbank. How do we tag rivers as they open out, turn into esturies, and then flow out to sea. The Proposed features/Tidal Rivers proposal offers an answer which seems sensible to me. -- Harry Wood 15:53, 2 November 2007 (UTC)

i believe, if there is no inteception to the coastline we should leave lakes lakes

sorry my behalf is by this time to find a way to track naval data

skaal to norge

User:CyberNautiker 01:40, 1 August 2009

anti-clockwise?

Am I crazy? The page says "The coastline should run anti-clockwise, i.e. land on the left side and water on the right side of the way...". Wouldn't anti-clockwise be land on the right and water on the left? - Dillwead 03:42, 28 March 2008

Ermm... you're crazy..
Ah wait. I can think of one possible way you might be getting confused. It's anti-clockwise around the areas of land... but if you're viewing it as following around an area of sea, it's clockwise around the area. Either way it's land on the left side and water on the right side (viewing from the direction of the arrows of the way)
-- Harry Wood 10:02, 28 March 2008 (UTC)

High water or low water?

Is the natural=coastline way expected to follow the high water mark or the low water mark? So far I've been tracing the water line on the yahoo images (which mostly seems to be lowish tide around here), but this really needs to be clarified. (See also Proposed_features/Water_cover for discussions about tidal areas).

I don't expect any kind of real accuracy when it comes to plotting high and low water marks since ideally it would need to be done at lowest/highest astronomical tides, but ins some areas (such as the Bristol channel), the tidal range is extreme and the high water mark and low water mark are sometimes over a kilometre apart (we can certainly manage better accuracy than a kilometre :) -- Steve Hill 14:34, 14 April 2008 (UTC)

The approach I have been taking is to tag natural=coastline as an approximation of high water. Any area of sand which is normally above the high water mark I have tagged as natural=beach. To tag the coastline as the low water line would I believe in many instances give an outline which would not be recognisable to most people as "the coast". As an example see the area to the North-East of Ryde, Isle of Wight, UK [1], On the low-res Yahoo image you can see a spit of light yellow / green extending over 1 Km from the marked coast. This is Ryde Sands, a sandbank which is uncovered at low water. Had I used the outline of this to tag natural=coastline it would have resulted in the outline of the Isle of Wight including this sandbank, and would not have been anything like what anyone would expect a "map" of the Isle of Wight to look like. Dmgroom 18:07, 14 April 2008 (UTC)
Are you tagging anything below the high water line at all? So far, I've been creating beaches between the (approximate) high and low water lines with water=tidal. Being able to map things between the high and low water marks is sometimes quite important - for example, footpaths often go across tidal stretches of beach, and there may be points of interest (such as wrecks, etc) in tidal areas too, not to mention the large areas of salt marsh. OS maps draw the sea as far as the mean low water mark and then have another line for the high water mark. -- Steve Hill 19:25, 14 April 2008 (UTC)
I'm Currently not tagging anything below the high water mark, because I hadn't felt there was an appropriate approved tag. I guess what I would argue is, for the reasons stated in my paragraph above, natural=coastline should be tagged as the high water line (so the outline of the coast looks 'correct' at low zoom) and that features below high water be marked as a separate layer, rendered on top of the blue for the water at higher zoom levels. Dmgroom 08:18, 15 April 2008 (UTC)
Ok, can we clarify on the map features page that natural=coastline is for (roughly) the mean high watermark? As for approved tags - I agree that there doesn't seem to be anything appropriate, but my view is that there is no harm in using the proposed tags since once the data is there it can quite easily be migrated to a new set of tags once they are approved (if they happen to be different from the proposed ones that were used). Being able to tag stuff below the high water mark is useful because it means people can see that "walking over that bit of beach is going to leave me waist deep in mud", etc. even if the water line itself isn't that accurate. :) (That said, the renderers need some work here - at the moment Osmarender is rendering all the beaches as sandy) --Steve Hill 08:49, 15 April 2008 (UTC)
I agree. The vast majority of our natural=coastline ways will be based on PGS data for a long time to come, and some will be corrected based on Yahoo! Aerial Imagery (variable tide level), but yes we should definately be clear about exactly how the line should be positioned, so that people can start to fix up the data while out surveying. "(roughly) the mean high watermark" sounds good to me --Harry Wood 16:24, 15 April 2008 (UTC)

As we have both: high water and low water - we need both: high water and low water.

Level abbr. what for
Mean High Water MHW land
Lowest Astronomical Tide LAT sea
the area between is "drying land"

In non tidal waters we use:

Mean Sea Level MSL land and sea

--Markus 23:26, 14 January 2009 (UTC)

I'm trying to understand the reasoning behind the idea of having the coastline positioned at Mean High Water, and the consequences for mapping tidal areas. I can't see any mention of how tidal areas are to be mapped in the coastline proposal. I guess that the coastline proposal was made in isolation without thinking about tidal areas, but they are interlinked, so you can't really decide one without resolving the other at the same time. (I've also added something to the Proposed_features/Water_cover talk page specifically on the details of that proposal).

The main justification for having the coastline at the Mean High Water seems to be the one given above by Dmgroom, which could be paraphrased as "the Mean High Water line is the line which produces a coastline that is most recognisable in the current renderers". However, that seems to me to be a weak justification because it is just "tagging for the renderer" (and many maps do show the tidal areas without seeming to destroy the recognisable shape of the coast)! If the coastline was positioned at Mean Low Water, with a separate tidal area up to Mean High Water and the beach area above that, then that would be a valid representation of the features and there's no reason why the renderers couldn't render the tidal areas as the same blue as the sea to achieve "the most recognisable coast shape" (if that's what the renderer writer wants to do).

If the coastline is positioned at the Mean High Water level, how are tidal beach areas to be mapped? I can think of a number of different ways, like a) extend the beach area down to the Mean Low Water (with the tidal area overlapping the sea) or b) add a separate tidal area below the beach (completely overlapping the sea), however these would only work if the renderers do something to decide how to render the overlapping areas (probably depending on the zoom level). I guess that the decision may be influenced by how the current renderers work. Maybe it's more efficient for them to do it in a particular way - "add" the tidal areas to the Mean Low Water sea or "subtract" the tidal areas from the Mean High Water sea - (I've no idea how they work, but it would be good to get input from someone who knows the details of how the renderers work with the coastline in case one way is better than the other!).

I'm not arguing that the coastline should not be at Mean High Water, but I want to get a logical explanation of how to map tidal areas if the coastline is at High Mean Water. Because the two things are interrelated, it's difficult to decide where the discussion on this should take place, either here or Proposed_features/Water_cover talk page. Maybe here is best, unless it's specifically about the Proposed_features/Water_cover? If it's about why the coastline should be at Mean High Water (or not) then here, obviously! --Spod 08:14, 30 April 2009 (UTC)

I don't think the renderers as such care either way - coastline is just rendered before anything else and drawing the tidal areas over that is the same as drawing "on land". To me the main motivation for using high water level is that most users operate on the dry side of that coastline position. At the moment the Mapnik rules seem to render anything tagged as a beach over the sea. I've personally split the only beach near me in two parts at the high water level and tagged the area between the high and low water levels as beach + tidal=yes. It'd be easy to use a different style (slightly bluish or such) for the tidal part of the beach - or tag it as a wetland=tidalflat if appropriate. Alv 10:34, 30 April 2009 (UTC)
For more details see problems of coastlines and boundary. --Markus 13:14, 28 May 2009 (UTC)
Can you translate that information to something more understandable for me than german? I do not know a single word german, at least I am not able to read much out of it without constant use of translating software. If you want to reffere to discussions in other languages than English, please at least give us a rough translation to go with it. I cannot see that you have anything to add to the discussopns than mentioning a few of the points already meantioned, but in a different language. --Skippern 00:37, 29 May 2009 (UTC)

Name?

How to name seas, larger lakes an islands? Perhaps the regular name tag should be used only in cases where the coastline it self have a name? Do we need something like name_left and name_right? --Henriko 15:37, 28 May 2009 (UTC)

You name them with a node with a place=* and a name=* tag, not by naming the coastlines. --Cartinus 17:01, 28 May 2009 (UTC)
Ok. Thanks. But since a coastline might be very long, it will often be impossible for a navigator software to know the name of a sea or a larger lake, since the place node might be far outside its loaded dataset. If left and right names was included in the way, then the names will always be in the data set where they are needed.
If, with the left and right name approach, someone loads a dataset completely inside an irland then there wont be any infomation about the name of the irland. But I dont think it is relavant to display anyway in such a case.
--Henriko 21:10, 28 May 2009 (UTC)

"direction/interlinked ways/overlap" notes

I think it might be a good idea to remove these detailed notes about how you have to draw these coastlines for the renderers, or at least shorten them to a minal. They aren't much use when you want to edit these coastlines, sure you need the info I agree about that, but perhaps a bit more terse? Erik Johansson 12:01, 2 October 2011 (BST)

Maybe, but if there's a place for detailed information on how to map coastlines, then this page is it. We get a lot of questions about why a bit sea/land rendering is going wrong so it's good to try to spell it out fully. -- Harry Wood 10:07, 3 October 2011 (BST)

Proposed Megre of Page

I am proposing to merge this page with Coastline which contains essentially the same information. At present mappers need to look at both pages to get all the details of how to map coastline, and how it renders. Dmgroom 12:50, 7 May 2012 (BST)

coastline:survey_quality

For showing difference between good and bad quality data on coastlines, the maritime INT 1 standard from IHO have split coastline into two different forms of rendering, C1 for good surveyed coastline, and C2 for coastline where it has been drawn with insufficient or non-existing data. I suggest to add coastline:survey_quality=complete and coastline:survey_quality=inadequate on coastlines to make this difference. Wether the imported coastline belong to one group or other I do not know. I personally have begun adding coastline:survey_quality=complete when coastline have been aligned with Bing photography, or other sources of high resolution, and coastline:survey_quality=inadequate where I see that the coastline is clearly wrong, but are not able (dont have time) to fix it. --Skippern 17:29, 2 September 2012 (BST)

Tagging of Tidal lakes, ponds, lagoons etc

Hello all, There is a tidal pond/lake (about 1/2 mile by 1/2 mile) that is connected to the open sea by a channel which is about 20 meters wide and about 200/300 meters long. The whole lot is tidal and salt water (indeed it is a saltwater wildlife reserve). Should the channel and lake be tagged as a coastline as effectively that's what it is? --Abc26324 17:11, 26 June 2014 (UTC)