From OpenStreetMap Wiki
Jump to navigation Jump to 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)

Hi, i too wonder how this area should be tagged: the cove is connected by 3 rivers to the sea, one is modeled with coastline the others are just water. why? --JSmith (talk) 15:00, 11 October 2017 (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


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)

I've created some proposals to try to solve the intertidal zones:

--Iagocasabiell (talk) 11:38, 5 September 2019 (UTC)

I know that I am late more than by a decade but chart datums on most nautical charts are set by the lowest tide and not vice versa. The same goes for the maritime law where normal baseline is recognised at the mean low water. Therefore I strongly disagree with the practice of mapping coastline at high water. --VileGecko (talk) 07:05, 7 September 2020 (UTC)

I tend to agree with you, but on the other hand mean high water is usually very clear from a visual survey (green line of slime on rocks, line of loose seaweed, etc). On the other hand mean low water is an elusive limit that you can catch only as the tide changes. For an 'on-the-ground' map like OSM, I can see how it makes sense.
But these are definitional questions, and I can't see why a MLWS line can't be added in the way Iagocasabiell suggests above: that would give you all the info you need and mitigate the departure from usual chart practice.eteb3 (talk) 17:26, 7 September 2020 (UTC)
It's sensible for maritime maps and law to focus on the mean low water springs line, because this is the limit represents the edge of the navigable maritime environment. But OpenStreetMap is primarily focused on land-based uses, because that's most accessible to most mappers. When you are on the land, you mainly want to know what areas might be under water at high tide or high water season, so we map the high water lines of rivers, lakes, and seas. But I agree that it is also fine to map natural=mean_low_water_springs if you can confirm the location in your local area. And in between the high and low water lines, you can map beaches, mud flats, rock and other features: this is already commonly done. --Jeisenbe (talk) 05:13, 9 September 2020 (UTC)


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)


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)

Yes, tag tidal, salt water lagoons like this with `natural=coastline`. If there is a name, you tag this with `natural=bay` on a node or area, in addition to mapping the coastline --Jeisenbe (talk) 00:47, 3 September 2019 (UTC)

Example of islet with two natural=* tags

Can someone give me an example on how to map an islet (for example) with natural=coastline and natural=bare_rock as stated in the wiki page? "An example would be natural=coastline;bare_rock for islets, which should be represented as natural=coastline as a member of a multipolygon relation tagged with natural=bare_rock." --AntMadeira (talk) 21:37, 7 January 2022 (UTC)

Can you give example of a 100% rock islet that you want to map this way? 23:44, 7 January 2022 (UTC)
This one. I separated the boundary=administrative from the islet, because it appeared as an admin_level=6 region, but I'm not sure the islet is 100% ok. --AntMadeira (talk) 23:59, 7 January 2022 (UTC) (in iD - select way, click + in relations section, select multipolygon, line should have an outer role, add tags to the area) 01:35, 8 January 2022 (UTC)
Thanks. I had tried that, but I was missing the outer role in the natural=coastline way. I think this should better explained in the wiki. --AntMadeira (talk) 02:43, 8 January 2022 (UTC)
See new Tag:natural=coastline#Example Mateusz Konieczny (talk) 11:49, 8 January 2022 (UTC)
Thanks a lot! This will surely help others to better understand how to map this kind of features. --AntMadeira (talk) 15:17, 8 January 2022 (UTC)

way or area for closed way?

If a feature like coastline is used on closed ways but isn't an area, how is that stated in description box (Key/ValueDescription) and data item? There is only the choice between "onWay" and "onArea". For Tag:natural=coastline now there has been set onArea=yes in English, but not so in other languages and on the data item. --Chris2map (talk) 19:59, 26 February 2022 (UTC)

Hi, see the comment in the history Best regards --Fred73000 (talk) 13:39, 6 March 2022 (UTC)

Land bridge extends over coastline

I'm wondering how to map places where there is land above the coastline. For example, a sea inlet (cave) with cliff tops above and then the sea opens inland, or a natural arch that you can pass under in a kayak with one end in the sea and the other connected to the mainland Currently these bits of sea are ignored in these locations but I wonder if they should be mapped and then an area with natural=* and layer=1 added? TrekClimbing (talk) 06:55, 11 August 2022 (UTC)

natural=arch. Not sure about cliffs. --- Kovposch (talk) 09:20, 11 August 2022 (UTC)
Thanks. I have used that where there's an arch, but it really doesn't say anything about the sea (could be an arch on land), and it doesn't really seem appropriate for a deep cave (which may or may not have a collapsed roof further along. Perhaps coastline is wrong but some mapping of open water seems appropriate. TrekClimbing (talk)
Not totally necessary to tag it's on the sea. What if it's above a lake or something else? A spatial relationship within the natural=coastline, natural=water, etc is good enough. Whoever is interested can analyze it independently. What do you mean by a "deep cave"? Is it enclosed like a real cave? natural=cave exists.
Anyway, perhaps you can start by trying to add layer=* if this makes sense? There's nothing for something hanging. Other status has floating=*. Maybe location=overhead, although that's not high enough a descriptor. In general, OSM is not good at 3D entities. There's a dozen arch=*, but they are not used for natural=arch or its environs yet.
natural=coastline is correct in that it reflects the water line. It obviously doesn't rise to above surface.
--- Kovposch (talk) 03:29, 12 August 2022 (UTC)
For cliffs, even on land, the contour is not that exactly defined.. So not to mention the landmass over water. Need something else for the hanging area. --- Kovposch (talk) 03:37, 12 August 2022 (UTC)
The way the natural=coastline is currently mapped for these is as a satellite image with all of the bits of sea that go under land not mapped. I was thinking it should be changed to be the waterline as described in the wiki with then a separate area with e.g. natural=rock | layer=1 for the hanging bit. I'm now thinking natural=coastline should stay as-is because it's at least as much about the extent of the land as the sea. Then add an area natural=water | layer=-1 | salt=yes for the bit of sea surface under the land bridge. It's just unusual to use natural=water for the sea.
By 'deep cave' I meant it is a long tunnel through the rock inland (filled with sea and air). However, at the far end the roof has collapsed so it is not completely enclosed and some sea is visible looking down through the hole. See aerial imagery and cadastral layer (waterline) here TrekClimbing (talk) 05:31, 12 August 2022 (UTC)