Re: [Tagging] Coastline for rivers, estuaries and mangroves?

[Malcolm Herring]

On 03/09/2018 19:24, Paul Allen wrote:

I expect somebody has a better definition.


Just to muddy the waters (pun intended!):

In its catalogue of chartable objects for electronic charts, the IHO 
originally defined "coastline", "river bank", "canal bank" and "lake 
shore". However, when it came to the implementation, they abandoned 
these distinctions and mapped everything as "coastline"



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Slipway vs boat ramp

[Malcolm Herring]

On 03/05/2018 17:14, Mike H wrote:

there are two different kinds of slipway


Yes, but both are commonly called "slipway". See 
:https://en.wikipedia.org/wiki/Slipway



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Coastal beach definition for mapping.

[Malcolm Herring]

On 04/04/2018 12:40, Eugene Alvin Villar wrote:
It seems some mappers go to the extreme opposite and map the coastline 
across the mouth of an estuary that is clearly part of the ocean:





Many ocean/river boundaries are not arbitrary, but reflect official 
boundaries where a coastal authority's water ends and a river 
authority's water begins.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

I think from all the cases presented in this thread, we could perhaps 
frame two broader definitions:


1. A lighthouse is a building that has a lamp room at the top.

2. A beacon is a mast surmounted by a light.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

On 18/01/2018 15:27, Janko Mihelić wrote:
I'm in the process of making a new icon, and I can make a pull request 
on the openstreetmap-carto soon.




That is good - maybe it will prevent mappers using "lighthouse" just so 
that a symbol is placed on the map.


I have added some more examples of non-maritime beacons to the tag page


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

On 18/01/2018 13:52, Janko Mihelić wrote:
I looked at man_made=beacon. Taginfo says we have about 7 000 of those, 
and the wiki shows something that resembles what we are talking about, 
but not quite:




man_made=beacon *is* the appropriate tag for such structures. Tags in 
the "seamark" namespace relate only to the *navigational function* of an 
object, not the physical form. Many beacon objects have no navigational 
function & therefore do not carry "seamark" tags.


It is important mappers doing a surveys can apply correct tags to 
observed objects without any knowledge of their function.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

On 16/01/2018 10:25, Andrew Davidson wrote:

OK. So a lighthouse has to have a rotating light then?


A lighthouse does not have any particular type of light, or any light at 
all, but it will have a lamp room at the top



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

On 16/01/2018 08:43, Martin Koppenhoefer wrote:
probably with exceptions, e.g. this is a lighthouse from 1911 (i.e. 
historic) with a lattice structure, generally considered a lighthouse:

https://en.wikipedia.org/wiki/Adziogol_Lighthouse


I can see a house!

To be clear, the OP asked what the difference is between a lighthouse 
and a beacon, not the difference between a major light and a minor 
light. The two classes of objects overlap, but are not equivalent. Only 
objects that have a maritime navigation function carry "seamark" tags. 
Many lighthouses & beacons do not.


There is obviously a grey area between lighthouses & beacons. To tag an 
object as either requires some degree of subjective judgement, since the 
distinction is one of the structure's grandeur.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

On 16/01/2018 00:21, Graeme Fitzpatrick wrote:
In what way would you consider that these are not lighthouse's? Just 
because they don't have accommodation?


Point taken. I was referring to the historical structures rather than 
any modern replacements.


The main point that I was trying to make is that a simple pile or 
lattice tower with a light on top should not be tagged as 
man_made=lighthouse, but man_made=beacon.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

On 15/01/2018 14:29, Martin Koppenhoefer wrote:

can you please explain how to distinguish a beacon from a light house?


Historical beacons (for which the tag man_made=beacon is appropriate) 
are structures that were for generic signalling purposes, not 
necessarily maritime navigation. They can found inland as well as on 
coasts. They usually take the form of either a masonry tower with an 
open top or else a simple pole with a fire cage on the top.


Maritime navigation beacons, on the other hand, can take many forms - 
everything from a tree branch driven vertically into the seabed, through 
poles, piles to masonry or metal lattice towers. They can be on the 
coast or offshore. They may or may not have lights. They are usually 
painted in internationally recognised colour schemes & may be topped 
with cones, cylinders or spheres. The colours & top shapes indicate the 
navigation information or warning.


A lighthouse (man_made=lighthouse) is a tower with living quarters 
either within the tower, or a separate structure at or adjacent to the 
base. They are topped with a lamp room. The lamp may or may not be 
functional - many lighthouses have been decommissioned from their 
navigation role. The distinguishing feature to differentiate lighthouses 
from masonry beacons is the ability to be lived in (do they have a door 
and at least one window?) and an enclosed lamp room at the top.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between lighthouses and beacons

[Malcolm Herring]

On 14/01/2018 13:47, Janko Mihelić wrote:
So a fuzzy rule can be created, you can't have a man_made=lighthouse tag 
and seamark:xxx=yyy tags on the same object. That's instantly an error. 
Seamark tags are used for instruments that help navigation, and 
lighthouses are structures that can house those instruments. But they 
are not the same thing. So a lighthouse can be an area with a seamark 
node at the place where the light is.


Is this generally accepted?


No. Lighthouse objects mapped as building outlines should have any 
seamark tags on the way as opposed to a separate node. This arrangement 
is easier to maintain. As most lighthouses have their lamp centrally 
placed in the building, the light position can inferred by calculating 
the centroid of the area.


The bigger problem is defining exactly what is a lighthouse & what is 
just a beacon. I agree that a lighthouse should be a building with 
living quarters. Often beacon towers, whether masonry or metal towers 
that support a navigation light are tagged as lighthouses - which is 
incorrect. Part of this is 'tagging for the renderer', so that a symbol 
is placed on the main map, but often it is the lack of a clear 
definition of a lighthouse.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is the unit of seamark:light:range?

[Malcolm Herring]

On 10/01/2018 13:53, Jo wrote:

Let's hope there is consensus on this.


There is certainly consensus among all the Seamarks consumer 
applications. To change the current tag values would break them all!



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is the unit of seamark:light:range?

[Malcolm Herring]

On 10/01/2018 06:50, Jo wrote:

Do we add " nmi" to all of them?


No. I have updated the Seamarks wiki pages to specify nautical miles as 
the default unit for ranges.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is the unit of seamark:light:range?

[Malcolm Herring]

On 09/01/2018 22:32, Mateusz Konieczny wrote:

What is the unit of seamark:light:range? It is not explicitly defined
athttps://wiki.openstreetmap.org/wiki/Seamarks/Lights

Nautical Miles


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] marine traffic control towers

[Malcolm Herring]

On 30/07/2017 21:35, Volker Schmidt wrote:
I am not sure whether "my" tower is a VTS one. It is known locally as 
"pilots' tower". I have not checked the signs on the door, to be honest.


Port pilotage is one of the functions controlled by VTS stations. If you 
live within 30NM of this structure, listen on Marine channel 13 to hear 
what is going on there.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] marine traffic control towers

[Malcolm Herring]

On 30/07/2017 16:59, Volker Schmidt wrote:
I suppose Martin is referring to**the marine equivalent  of Area Control 
Centers for air traffic (ACC). But that's different from the structure I 
have in mind as it's not in visual contact with what is going on "below" 
the tower.


There is no marine equivalent of Area Control Centres. The VTS stations 
that this thread refers to are usually operated by port authorities and 
only control the traffic in their jurisdictions. Some busy sealanes 
(e.g. Dover Strait/Pas de Calais) are controlled by coastguard services 
as they do not control the traffic of any particular port.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] marine traffic control towers

[Malcolm Herring]

On 29/07/2017 09:39, Volker Schmidt wrote:
What's the correct term and tagging for marine traffic control towers or 
similar buildings?




No tags have been defined as far as I know. This may of help: 
https://en.wikipedia.org/wiki/Vessel_traffic_service



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=industrial with industrial=port

[Malcolm Herring]

In the port area where I live, fishing, ferries, cruises, general 
cargoes, oil and gas terminals, ship repairs, offshore support, wind 
turbine construction & shipment are all handled.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=industrial with industrial=port

[Malcolm Herring]

On 22/02/2017 13:13, Martin Koppenhoefer wrote:

What I haven't decided yet is whether to propose using a property like
seaway:terminal
=yes
to distinguish terminals (route endpoints) from other ports, or if we
use different main tags like this:
seaway=ferry_port or seaway=ferry_terminal


In general ports are not of singular usage. Some shipping services may 
terminate at a particular port, but others may not. There may also be 
differing service types carried on at one port.


Therefore any attribute tags must allow for multiple values.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=industrial with industrial=port

[Malcolm Herring]

On 21/02/2017 08:45, Martin Koppenhoefer wrote:

IMHO there should be a feature tag for ports (e.g. man_made=port) not just an 
indirect way of mapping landuse properties.


Agreed, but not "man_made", which I think should only used on singular 
objects. A port is much like a small town or an industrial park. May I 
suggest "port=*", where the default value would be "yes" and specific 
values would specify the type of port (container, passenger, etc.).



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=industrial with industrial=port

[Malcolm Herring]

On 21/02/2017 07:52, Stefano wrote:

I use already my proposal, I haven't migrated to the correct page, but
it's here
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dport



Stefano,

Your proposal is to have "landuse=industrial" + "industrial=port". That 
would in most cases mean just adding the latter tag to the many ports 
that are already tagged with the former. It would have the advantage of 
not breaking any consumers that expect "landuse=industrial".


Those ports tagged "landuse=port" would need to be re-tagged with your 
proposed pair. Those tagged "landuse=harbour" would have to be reviewed 
one-by-one as some instances are on port areas, but many are in fact on 
harbour areas, where "harbour=yes" would be appropriate.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=industrial with industrial=port

[Malcolm Herring]

PS: I was going to propose "landuse=port" as an obvious choice.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=industrial with industrial=port

[Malcolm Herring]

On 20/02/2017 20:14, Martin Koppenhoefer wrote:

agreed, the wiki page titled 'Harbour' gives an overview of both, maybe the 
page should be renamed


I could rename it "Harbours and Ports" and add text to cover ports, but 
first I need some agreed tagging for ports. That was the question asked 
in the OP. Most of the instances of "landuse=harbour" are over areas 
that are in fact port facilities. Other port areas tend to be tagged 
"landuse=industrial".


Maybe someone can propose a port specific tagging?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=industrial with industrial=port

[Malcolm Herring]

Ports and harbours are not the same thing. A harbour is merely a 
sheltered body of water protected by man made or natural structures. A 
port, on the other hand, is the whole infrastructure for handling ships 
& their cargoes. This may include any number of harbour areas, but also 
wharves, piers, docks, quays, warehouses, terminal buildings, admin & 
customs offices, etc.


So such areas would be better served with a 'port' tag of some kind.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Use of oneway=yes on waterways

[Malcolm Herring]

On 18/09/2016 11:14, Colin Smale wrote:

the values for "oneway" and all the "forward" and "backward" subkey
business are geometric directions related to the order of the nodes in
the OSM way,


This is a dangerous dependency - if the way is reversed by another 
mapper, the all "oneway" tags become invalid.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Use of oneway=yes on waterways

[Malcolm Herring]

On 17/09/2016 23:08, Colin Smale wrote:

Martin, are you suggesting to drop the convention for the way direction
that it goes with the flow? Or are you OK with oneway=reverse?


Values such as "yes", "forward", "reverse", "-1", etc are all 
meaningless to those who actually navigate the waterways. As Aun said, 
the commonly understood terms are "upstream" & "downstream".



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=fairway?

[Malcolm Herring]

On 18/07/2016 10:02, Martin Koppenhoefer wrote:

in the more common natural, waterway, man_made etc. namespaces


Indeed we do encourage the usage of mainstream OSM tags for all natural 
& cultural/manmade objects. Where seamark tags are added to these 
objects, it should be only to indicate additional navigational information.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=fairway?

[Malcolm Herring]

On 18/07/2016 08:53, Martin Koppenhoefer wrote:

why "seamark:*"?


This is historical. At the beginning of nautical navigation mapping, it 
was buoys, beacons, lights, etc that were being mapped. As is usual with 
OSM mapping, feature creep set in to include all objects listed in the 
IHO catalogue. In retrospect, a broader term than "seamark" would have 
been better, but like many other ill-fitting tag keys, we are stuck with it.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=fairway?

[Malcolm Herring]

On 18/07/2016 07:50, Volker Schmidt wrote:

but they for sure must have same tags for that.


Yes: "seamark:type=fairway". Ideally on a polygon, but a linear way will do.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] values with ";" and overpass

[Malcolm Herring]

On 14/07/2016 20:09, Bjoern Hassler wrote:

way["line"="Jubilee"]({{bbox}});


Try:
way["line"~"Jubilee"]({{bbox}});



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Masts vs Towers yet again

[Malcolm Herring]

On 15/04/2016 17:17, Martin Koppenhoefer wrote:

do you agree to use tower for communication towers?


Yes. My suggestions relate to the form of the structures, not their 
usage. Those would be defined by secondary tags.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Masts vs Towers yet again

[Malcolm Herring]

On 15/04/2016 12:39, Dave Swarthout wrote:

I think you had better make the requirements for tower less strict.


The whole point of my definitions is to *NOT* use the word "tower" for 
communications masts. I am trying to resolve the ambiguity by choosing 
one in preference to the other, even though a given structure may be 
locally known by the other word.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Masts vs Towers yet again

[Malcolm Herring]

This is a continuation of a discussion started in the devel list. The 
issue is the definitions of "tower" and "mast".


The two terms are used interchangeably in both UK & US english, 
resulting in a lack of consensus for tagging.


Perhaps we should define a "for use in OSM tagging" definitions of these 
terms, simply to fix a convention. I will try a proposal:


Tower: Any free-standing structure of high vertical aspect ratio that 
has some kind of accommodation within it (observation decks, 
restaurants, offices, apartments, etc)


Mast: Any structure of high vertical aspect ratio that has no 
accommodation (apart from service access), commonly used for 
communications purposes & may or may not be free-standing.





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - shop=boat (supersedes shop=marine, shop=*chandler, etc)

[Malcolm Herring]

On 14/04/2016 00:28, anarcat wrote:

boat_supplies was*never*  mentionned in this thread prior to this post,


It was, but somebody broke the thread. The subsequent discussions 
continued in both fragments. If you view this list in thread view, the 
separated fragment is immediately after this one.


This is a common problem in mailing lists, so it is always necessary to 
to view all topics, not just rely on following one.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - shop=boat (supersedes shop=marine, shop=*chandler, etc)

[Malcolm Herring]

On 11/04/2016 19:20, anarcat wrote:

Yet shop=boat itself was never formally proposed or discussed here, as
far as I know.


shop=boat is a bad choice for marine/chandlery stores. A better tag is 
shop=boat_supplies as this more completely describes the type of store. 
Few chandleries sell actual boats, so just as we have shop=car and 
shop=car_parts to differentiate between two quite different entities, so 
should we use shop=boat for places that sell boats and 
shop=boat_supplies for chandlers/marine stores.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=marine RFC

[Malcolm Herring]

On 15/03/2016 11:02, Colin Smale wrote:

How would you define "small" in this context?



Any pleasure craft, from one person inflatable dingies to luxury 
cruisers, and from sailboards to Larry Ellison's behemoth.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=marine RFC

[Malcolm Herring]

On 15/03/2016 09:42, Martin Koppenhoefer wrote:

and do you go to the same shops?


Yes. Chandleries cater for all types of small craft.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=marine RFC

[Malcolm Herring]

On 15/03/2016 09:31, Richard Fairhurst wrote:

Some of us have boats (not ships) with engines (not sails).:)


+1!

Maybe "shop=boating_supplies"?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=marine RFC

[Malcolm Herring]

The common name for such shops is "chandler". This is more specific to 
the type of shop you want to tag. "marine" is too broad a term



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wharf

[Malcolm Herring]

From the IHO Hydrographic dictionary:

breakwater. A structure protecting a shore area, HARBOUR, ANCHORAGE, or 
BASIN from WAVES. See also FLOATING BREAKWATER.


jetty. In U.S. terminology, a structure, such as a WHARF or PIER, so 
located as to influence CURRENT or protect the ENTRANCE to a HARBOUR or 
RIVER.
In British terminology, a PIER, usually of solid construction, intended 
as a berthing place for vessels. See DOCK, LANDING, WHARF.


mole. A massive structure of masonry or large stones serving as a PIER 
or BREAKWATER, or both.


pier. A long, narrow structure extending into the water to afford a 
berthing place for vessels, to serve as a promenade, etc. See also JETTY.


quay. A WHARF approximately parallel to the SHORELINE and accommodating 
ships on one side only, the other side being attached to the SHORE. It 
is usually of solid construction, as contrasted with the open pile 
construction usually used for PIERS


wharf. A structure serving as a berthing place for vessels.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wharf

[Malcolm Herring]

On 16/02/2016 17:41, James Morrison wrote:

Is there a specific difference between mole and breakwater?


Yes, in both form and function. Breakwaters only serve to attenuate 
waves and are not designed for mooring. They are usually parallel to, 
and detached from, the shore and are often awash at high tide.


If a structure is both attached to the shore and has a mooring function, 
then it is either a mole or a pier.


As I said in my OP, all of these structures are frequently misnamed.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wharf

[Malcolm Herring]

On 16/02/2016 16:48, Jean-Marc Liotier wrote:

So is a mole a special sort of pier ? Then definition of "pier" in
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpier is wrong, as it
is not always "a raised walkway over water supported by pillars".


That definition of a pier is correct. Water flows under a pier but not a 
mole. So the outline of the projecting area of a mole is part of the 
coastline (or riverbank) whereas a pier is not. I use the tag 
"man_made=mole". Tags with "pier" in either key or value are 
inappropriate for a mole.


Also, to complicate the issue, there is also an "open-faced wharf" as 
opposed to a "solid-faced wharf" (the usual case). An open faced wharf 
is a pier-like structure (i.e. a deck on piles over the water) but 
alongside the shore rather projecting from it.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wharf

[Malcolm Herring]

On 16/02/2016 14:26, Jean-Marc Liotier wrote:

"môle" - which is a much better translation for "wharf"


No it is not - a mole (also an english word) is a solid pier - it is 
masonry/stone/concrete structure that is built on the seabed & has the 
function of a pier. The important difference is that a mole projects 
from the land like a pier, & is not part of the land like a wharf/quay.


Beware of local misnaming of all of these structures.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Malcolm Herring]

On 27/01/2016 18:06, markus schnalke wrote:

When we agree on the conceptual need,*then*  we can and should
discuss implementations.

+1


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Malcolm Herring]

On 27/01/2016 16:36, Frederik Ramm wrote:

One thing that I would like to see discussed is ordering.


There should be allowance for both ordered and unordered multiple 
values. Whether this is left to the producer/consumer tools or indicated 
in the tag template is debatable. In the former case the tag definition 
should be documented to indicate the interpretation of multiple values. 
In the latter case, a solution such as different delimiter characters 
would be needed - maybe semicolon for unordered and commas for ordered?



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Discussion about Multivalued Keys

[Malcolm Herring]

On 27/01/2016 17:02, Matthijs Melissen wrote:

Do you have an demo rendering (screenshot is fine) for that?

http://opennauticalchart.org/?permalink=true&zoom=18&lat=53.73980&lon=-0.33991&seamarks=true&coordinate_grid=true

Here you will see examples with 1, 2 & 3 values


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Move tag to a subtag (landuse=port)

[Malcolm Herring]

On 18/08/2015 15:45, Stefano wrote:

What's your opinion?



It is important to distinguish between a port and a harbour, dock or 
terminal. These are often confused, and I see this confusion in 
reference [0]. A port is an administrative entity, whereas 
harbours/docks/terminals are physical entities. A port may contain any 
number of harbours/docks/terminals (>=0) as well as other buildings or 
areas of land not contained with the boundaries the 
harbours/docks/terminals.


Any tagging scheme for these entities should take into account these 
important differences.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Telecoms Tagging

[Malcolm Herring]

On 02/08/2015 22:10, Tim Waters wrote:

Is a loop
a mappable thing


In the telecom context, "loop" is a synonym for "circuit", i.e. a pair 
of wires, twisted together and is always a point-to-point connection 
(linear (non-closed) way in OSM mapping).



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multiple values with semicolons (was: Voting - Blood donation 2)

[Malcolm Herring]

On 20/07/2015 21:45, Friedrich Volkmann wrote:

The only solution is to split the object (e.g. 2 separate nodes).


Not so - a tag of the form := would allow more 
than one object to be separately tagged on the same node or way.


e.g.:
pub:opening_hours=*
hotel:opening_hours=*


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] dock=tidal

[Malcolm Herring]

On 29/05/2015 13:16, John Eldredge wrote:

That is just one of the common meanings of dock. Another common meaning
is as a synonym for pier, an above-water structure used to give access
to a ship.


You are referring to the en-us usage of the word "dock", which covers 
piers, pontoons & the like. OSM renders waterway=dock as water, as would 
be expected for en-gb (and IHO) usage.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] dock=tidal

[Malcolm Herring]

On 29/05/2015 09:45, pmailkeey . wrote:

Is, then, a dry dock an empty body of water?



Only when it is pumped dry.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] dock=tidal

[Malcolm Herring]

On 29/05/2015 08:41, Bryce Nesbitt wrote:

Why is this a property of the dock,
rather than a property of the water body.


A dock is a body of water. It may or may not be separated from a 
connecting river or sea by a lock or single gate.




What's wrong with "floating" vs. "fixed"?


What do you mean? Is this a general question or a tagging suggestion?



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] dock=tidal

[Malcolm Herring]

On 28/05/2015 22:16, 715371 wrote:

So what do you think about deprecating the usage of dock=tidal as it is
proposed at the wiki and propose the opposite? In that case I would
propose something like dock=basin or dock=managed_water_level.


It does seem that the definition given in the Wiki is inverted. My 
understanding of a tidal dock is one where there is no lock or gate 
between the dock and the connecting tidal waters. Hence the water level 
is not managed.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Way inside riverbank

[Malcolm Herring]

This idea of the linear river way being along the deepest part seems to 
have been created in this thread. No such 'rule' exists, either in 
practice, nor in Wiki tagging pages. The normal usage is to place the 
way along the approximate centre line of the waterway, just as we do 
with roads.


As to the direction, this usually can be determined by watching the 
water flow, or simply by knowledge of the surrounding topography. There 
are some problematic cases:


1. Contour canals have no flow. The direction or the way is arbitrary.

2. Canals that pass over summits flow away from the summit reach, so the 
way must be split into two opposing directions at the point of the 
feeder reservoir. Likewise at lowest reach between two summits.


3. River deltas often have channels that cross between two branches of 
the same river. The direction of the way is arbitrary.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Way inside riverbank

[Malcolm Herring]

On 23/04/2015 03:30, John F. Eldredge wrote:

In my experience, rivers, unlike harbors, generally don't have buoys or
other markers showing the location of the navigational channel


Oh, but they do:

https://wiki.openstreetmap.org/wiki/OpenSeaMap/CEVNI_Lateral_Marks



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] areas (eg rocks) underwater and across coastline/water shores

[Malcolm Herring]

On 26/03/2015 16:24, Richard Z. wrote:

has the rendering of the tidal areas been defined somehow?



No. tidal=yes is ignored.


how about underwater:natural=* and awash:natural=* ?


No doubt others will come up with alternatives. I will stand back and 
wait for the usual suspects!



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] areas (eg rocks) underwater and across coastline/water shores

[Malcolm Herring]

On 26/03/2015 12:35, Richard Z. wrote:

How do people think about it? Should we generalise that approach
or seek another solutions?


The way I have approached this is to map separate areas above and below 
the natural=coastline way & add the tag tidal=yes on the below HW area.


Should we use underwater/awash tag or prefix?


The OpenSeaMap object underwater/awash rock (seamark:type=rock) only 
refers to isolated rocks rather than a rocky seabed. Therefore it is 
only appropriate on a node.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Malcolm Herring]

On 19/03/2015 17:41, Richard Z. wrote:

do you have any background info regarding the many
"obstacle" nodes which are present in German waterways?


I don't. I found a key:obstacle page in the Wiki that associates it 
OpenSeaMap - I don't know why the authors thought that. Those authors 
are unknown to me. Looking at the actual nodes, I see that they are 
mostly also tagged with the WSV import data.


As many of the obstacle=bridge tagged nodes date back to 2007/8, my 
guess is this is a case of tag 'infection'. The recent mappers would 
have found many bridges on German waterway had obstacle=bridge tags & 
assumed that this was the way to tag them, then included those tags in 
the import.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Malcolm Herring]

On 18/03/2015 11:58, Richard Z. wrote:

so should for example the OpenSeaMap tagging for bridges become
deprecated?


Not deprecated, but considered on a case-by-case basis. It is a question 
of whether important navigation information would be deleted if the 
seamark tags were removed. In the case of bridges, the safe air draft 
and beam are important attributes that should be kept, but a bridge that 
is absent those seamark attribute tags need not carry the 
"seamark:type=bridge" tag.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Malcolm Herring]

On 17/03/2015 16:06, Brad Neuhauser wrote:

Is there something I'm missing?


No, you have spotted the fact that (as always!) that the documentation 
is unfinished. I had done it on this page: 
http://wiki.openstreetmap.org/wiki/OpenSeaMap/INT-1_Cross_Reference but 
I need to add notes/links on the other pages to direct people to the 
appropriate tag:* and key:* Wiki pages.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Malcolm Herring]

On 17/03/2015 13:19, Martin Koppenhoefer wrote:

their tagging scheme is somehow a parallel universe,


Not parallel, but in some cases complimentary. For 95% of objects there 
are no overlaps with standard OSM objects. It is those 5% of cases that 
do overlap that people notice & hence assume that OpenSeaMap have an 
alternative set of tags for everything.


We always recommend that all natural and cultural features are tagged as 
per OSM Wiki & only add Seamark tags where there is a non-coincident 
definition and the nautical definition is of special navigational 
importance.


Locks & their gates do not fall into that category & so we do not 
recommend using Seamark tags for these objects. Where you may find them 
is probably where data has been imported from S57 ENC charts & the 
importer has not re-tagged (or double tagged) them.


Our renderer does understand both types of tags, although I cannot speak 
for the authors of other SeaMap consumer apps.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Malcolm Herring]

On 16/03/2015 16:35, Bryce Nesbitt wrote:

If you're a router following a way, having the node marked makes the job
easier.


Is that not "tagging for an app"?

A similar case is bridges. Here the bridge tag could be on a segment of 
the way over the bridge, the way under the bridge, a node on either or 
and area round the bridge structure. Any of these may carry attributes 
such as weight limit, headroom, etc. A smart routing app ought to be 
able to work with any of these cases, using the headroom for a route 
that passes under & the weight limit for routes that pass over.


This is the same for lock gates, which is a similar class of object - 
the waterway passes through (when open) and footways, etc pass over the 
gate (when closed). Wherever the tags are placed, any consumer app 
should be able to cope.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=lock_gate - is it only for nodes?

[Malcolm Herring]

On 16/03/2015 10:37, Richard Z. wrote:

I think it makes sense to tag them as ways, analogous to weirs and dams.


+1


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Survey points

[Malcolm Herring]

On 11/03/2015 14:43, moltonel 3x Combo wrote:

Adding a separate survey_point node would have
little benefit.


The problem in many cases is the "man_made" key. I come across many 
objects that were tagged "man_made=lighthouse", with other tags 
describing attributes of that structure, but then another mapper has 
come along and added the "man_made=survey_point" tag, that replaces the 
original tag. Often URL and other reference tags get overwritten as well.


This is why I am of the view that survey points should be mapped on 
separate nodes.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Survey points

[Malcolm Herring]

On 11/03/2015 11:57, Martin Koppenhoefer wrote:

maybe the tower has a point defined (e.g. top of the antenna or a sign
or similar) which could be a survey_point.


Since surveyors have to take bearings-from as well as bearings-to survey 
points, the point would have to be located where survey instruments can 
be set up. One would expect, therefore, that these points would be at 
ground level. That is how the Wiki illustrates them.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Survey points

[Malcolm Herring]

On 11/03/2015 09:46, moltonel 3x Combo wrote:

Care to review them ?


I took a quick look at these objects & the few that I examined were 
actually created as areas, rather than had been converted from a node. 
The most egregious example is this one: 
http://www.openstreetmap.org/way/199650922. It is a square with sides 
over 500m, and a note that reads "do not move this node"!!??



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Survey points

[Malcolm Herring]

OK, the mapper in question did not reply, but silently removed the tags. 
This leaves me none the wiser as to the more widespread usage of this tag.


Looking closer at the data, it appears that "man_made=survey_point" is 
very often added to prominent objects, particularly towers, masts and 
lighthouses. Could it be that some survey agencies use these objects as 
triangulation points? If so, it raises a couple of issues:


1. The "man_made" key should refer to the structure, not its usage.
2. The drift towards micro-mapping means that such objects, originally 
mapped as nodes, get converted to plan outlines and the tags moved to 
that closed way. If the intent of the "survey_point" mapper was to set a 
lat/lon positional reference, then that scheme is undone.


Might it not be appropriate to add a note in the Wiki page for this tag 
that it should not be added it to existing objects, but to always create 
a separate node?



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Survey points

[Malcolm Herring]

The Wiki is very clear (in several languages) as what a survey point is, 
but is there some other meaning that mappers understand this term to 
mean? The reason I ask is that I often come across man_made=survey_point 
tags that have been added to other objects. Not infrequently this tag 
replaces an existing man_made=* tag, even though other tags describing 
the original object remain. This then creates a nonsensical set of tags. 
I have just come across these tags added to some buoys in the middle of 
the River Maas! As is often the case, the changeset was un-commented, so 
I have added a query comment to see if I can discover what was in that 
mappers mind.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping private home toilets

[Malcolm Herring]

On 03/03/2015 13:30, Paul Johnson wrote:


On Mar 2, 2015 12:07 PM, "Bryce Nesbitt"
mailto:bry...@obviously.com>> wrote:

 > I'm opening a discussion about at least mechanically re-tagging
  operator:type=private
 > into "access=no" or "access=private", so that rendering software can
choose to omit these locations depending on the map purpose.

I'm supportive of this change.  Limited access toilets exist, I don't
see why we can't broaden the current definition of the tag to
disambiguate access.

In the case of private toilets, the issue is surely one of privacy. 
Within a private boundary, no "amenity" tags should appear at all. Where 
a toilet within that boundary is contained either within the main 
building or a separate building, then no toilet tags should appear at 
all. It is a private matter for the property owners as to the usage of 
their structures.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accuracy of survey

[Malcolm Herring]

On 23/12/2014 16:57, Tom Pfeifer wrote:

The collection of
   traces over a longer time creates a cloud of traces which
   form a Gaussian bell curve, in density, over the ground truth.


Except that the position of a node in the DB is the last edited value, 
not the mean position of all historical values.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Default maxspeed unit on waterways

[Malcolm Herring]

On 29/10/2014 14:12, Ilpo Järvinen wrote:

I don't know about other countries, but here in Finland the water maxspeed
signage is in km/h although knot is used for almost everything else.


In UK waterways, both MPH and knots are used. Usually MPH on canals and 
knots on rivers, though even this can depend on who the navigation 
authority is and how far back in history their statutes were written.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] cleanup of the key natural

[Malcolm Herring]

+1 if it means that the rendering of these features is done according to 
whatever is agreed. I have a particular interest in coastal and tidal 
riverbank areas. I had tagged some such areas some years ago according 
to the Wiki and the rendering was as expected. Since the introduction of 
Carto, the rendering rules between coastal and riverbank 
wetland/tidalflat sand/mud changed, causing abrupt changes in estuaries, 
where sea becomes river at some arbitrary point. Now recently, the zoom 
rules between mud and sand/beach have diverged.


In summary, I would like to see a set of tagging rules that produce 
predictable & consistent renderings in the map. I am agnostic as to 
exactly what these tags should be & will gladly change my mapping to the 
new scheme.


I will leave it to others to argue at length over what the tags should be!


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Port and terminals

[Malcolm Herring]

Most ports handle many different types of cargoes, so a single value is 
insufficient. It would be better to tag the individual terminal objects 
within a port with a type rather than assign a type to the port object.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Port and terminals

[Malcolm Herring]

To be consistent with the IHO definitions, any use of the word "harbour" 
should be used for the area of sheltered water and not any land areas. 
Those land areas adjacent to the harbour water should be classified 
according to their function (terminal, wharf, etc.) Therefore the tag 
"landuse=harbour" on areas that do not include the water does not make 
sense.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Port and terminals

[Malcolm Herring]

On 06/07/2014 10:45, sabas88 wrote:

Let me know how I can edit / disambiguate.

The important distinction is that a port is an administrative boundary 
(which may have several disjunct areas) whereas harbours, terminals, 
docks, wharves, basins, quays, etc. are physical features. Since those 
latter features will be administered by the port authority, they should 
all be within the port boundary(s).



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Port and terminals

[Malcolm Herring]

On 06/07/2014 08:24, nounours77 wrote:

=> So this would imply that "port" is a individual facility inside a
"harbour".
In fact it is the other way round. A port my contain one or more 
harbours. (In turn, a harbour may contain zero or more docks and a dock 
may contain zero or more basins.) A port may also contain one or more 
terminals. In smaller ports, the port and harbour may be co-incident, 
hence the ambiguity between these terms.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Coastline-River transit placement

[Malcolm Herring]

On 29/03/2014 20:29, Richard Z. wrote:

Currently there are essentially no rules at all on this matter


Nor will there ever be. OSM mappers are free spirits!


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Canal banks

[Malcolm Herring]

On 03/02/2014 14:34, Janko Mihelić wrote:

There wasn't a vote on deprecating riverbank, and it probably wouldn't
have passed.


waterway=riverbank: 260,000 instances
water=canal:2400 instances

I would suggest that the latter be deprecated, especially as the former 
is documented on the main map features Wiki page.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] OpenSeaMap tagging - seamark-prefix was Re: [Imports] IENC of the German WSV

[Malcolm Herring]

We (OpenSeaMap) are open to suggestions on this. The harbour project has 
recently been re-started after a hiatus of several years. As we are 
building a separate database to contain imports from various public 
harbour data sources. These harbour objects only require a simple 
"seamark:type=harbour" tag to cause our map to render an icon and pop-up 
data from this database with a mouse hover. The question is: how do OSM 
mappers contribute to this data? Hence the facility availability tags. 
(These tags have existed for years, but were rarely used).


I would be interested to hear (constructive!) ideas.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] IENC of the German WSV

[Malcolm Herring]

On 11/12/2013 09:29, Martin Koppenhoefer wrote:

It also seems odd to add all facilities as attributes to the main object
rather than mapping them inside the area at the place where they are (if
I understood that page right, the former is what it suggests). E.g.


It is not "rather than", but "as well as". The harbour object is tagged 
with a list of *available* facilities, the tag values being free text to 
qualify those availabilities. e.g. "harbour:toilets" could take the 
value "private, access by code". The actual location of these facilities 
are mapped separately, with appropriate tags, either from the "amenity" 
series or from the "seamark:small_craft_facility" series.


The reason for this arrangement is that querying a harbour object will 
bring up a list similar to those found in marina directories, nautical 
almanacs, etc.


Anyway, this thread is about the import, not the tagging! I know that we 
all love to argue about tags, but this is best done in the tagging list.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Telecoms local loops connections nodes

[Malcolm Herring]

On 20/11/2013 23:53, François Lacombe wrote:

Is "Central Office" the right english term for all kind of nodes ?


No. Central Office (North American term) or [telephone]exchange 
(UK/Ireland term) usually implies the location of a switch as well as 
the MDF and line terminations. However local loop nodes can be located 
remotely from a switch. Often these are in small cabinets, huts, etc. 
and contain the line termination (copper, co-ax or fibre) and a 
multiplexer to drive the back-haul (uplink) line to the switch location.


So in tagging tagging telecom network infrastructure, you need to know 
what equipment is present within a structure.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bridges redux

[Malcolm Herring]

On 09/05/2013 21:41, Christopher Hoess wrote:

I'm not absolutely set either way; since you bring it up, I'd like to
hear other people weigh in as well.



As a renderer developer, I see no problems with Richard's 
simplification. Renderers should always have a default for unrecognized 
types, since these are frequent, owing to typos and mappers inventing 
their own. My view is that the simpler the tagging scheme is, the better.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Malcolm Herring]

On 04/02/2013 18:54, Douglas Fraser wrote:

Have design decisions been made?


Only the design outline has thus far been discussed. In summary, any 
feature tagged as a port, harbour, marina or anchorage will have the 
relevant symbol rendered on the OpenSeaMap Seamark layer. The renderer 
will communicate the co-ordinates of this symbol to a separate database 
which will overlay an invisible button over that position in the 
OpenSeaMap Harbour layer. A right-click on the symbol will then invoke a 
pop-up panel that will display the meta-data. The Harbour layer database 
will have extracted the metadata form divers public database sources, 
including the OSM tags on any feature that invoked the Seamark layer 
symbol. This metadata would include LOCODEs where available.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Malcolm Herring]

On 04/02/2013 18:26, Douglas Fraser wrote:

The data management issues are important, so I'm inclined to update the
wiki page to direct people to OpenSeamap as that seems like a more
logical place to keep specialized metadata like this and they'd be more
inclined to keep the data updated.


OpenSeaMap currently map the physical features of ports, but not 
metadata. We do have a project underway to do this, but it is in its 
infancy. So if you need this anytime soon, please don't wait for us!



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tunnels and bridges

[Malcolm Herring]

On 01/02/2013 15:02, fly wrote:

4. Not only a problem of this thread but we need to get much more developers to
support relations (eg. renderes, editors, search engines and other consumers).
This includes evaluating existing relations and adjusting them to be useful.


+1
A relation explicitly establishes an intended association between 
features, whereas shared nodes do not. Many features share nodes, but 
have no intended association.




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tunnels and bridges

[Malcolm Herring]

On 31/01/2013 15:17, Martin Vonwald wrote:

As you already need to
split the roads at the edges of the structure, because you need to add
the layer (and bridge) key within the structure, there are already
nodes present - just connect them with the OSM way of the structure.


Why do you need split the road at the edges of the bridges? This is 
currently done because it is the only way of defining the bridge. If we 
are to split the two features, then this need disappears. If the bridge 
crossing ways have width or weight limits, these do not necessarily 
coincide with the structural limits of the bridges. They often apply to 
the approaches as well, so the section of the road where the restriction 
applies begins and ends beyond the bridge.




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tunnels and bridges

[Malcolm Herring]

Martin,

Maybe I am missing something from your proposal. I had understood it to 
mean that bridges should be mapped as distinct features, separate from 
the ways that pass over and under. Therefore, "bridge=..." tags on the 
ways would become redundant and remove the ambiguity and messy rendering 
that they cause when more than one way crosses the same bridge.


Also, wheat exactly did you mean by "Connect the ways running over the 
bridge to this structure"? This implies a relation to make the 
connections, but you then go on to deprecate the use of relations.


So I am confused!

Malcolm


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tunnels and bridges

[Malcolm Herring]

On 31/01/2013 13:44, Martin Vonwald wrote:

* =bridge : this is the tag we should decide one. I guess
the value "bridge" is unchallenged.


-1
If the primary tag is bridge=, then why do we need the above tag 
at all?



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tunnels and bridges

[Malcolm Herring]

On 31/01/2013 13:44, Martin Vonwald wrote:

* bridge= : use this tag just like it is used at the moment. If
the value would be "yes" it should be optional.


Again, borrowing from IHO, they define the following bridge types:

fixed
opening
swing
lifting
bascule
pontoon
drawbridge
transporter
foot
viaduct
aqueduct
suspension


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tunnels and bridges

[Malcolm Herring]

On 31/01/2013 12:37, Martin Koppenhoefer wrote:

drawing the outline seems a good approach as it permits to group
visually (and topologically) different carriageways running over the
same bridge (as opposed to two parallel bridges).


This is approach is used by IHO for marine chart data. Where a bridge 
has more than span, they further divide the bridge outline into two or 
more butted polygons, one for each span, so that each span can have its 
own height & width attributes. They also map bridge piers as separate 
objects.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Giant river multipolygons

[Malcolm Herring]

On 29/01/2013 10:42, Pieren wrote:

So just explain me why what you accept for administrative boundaries
is suddenly not good for rivers


It is the relation type that is at issue. The problems arise when the 
relation type is a multipolygon with all the outers & inners of the 
entire river as members rather than a separate relation (e.g., 
type=waterway) with all the riverbank multipolygons as members.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Giant river multipolygons

[Malcolm Herring]

On 28/01/2013 17:53, Toby Murray wrote:

But being able to do a search for
"Danube River" and getting back a single object from nominatim would
be nice.


Here is a conflict. Creating a tagging convenience for one tool can have 
negative impacts on other tools. At least nested relations separate the 
entities into logical hierarchies. Tools that are only concerned with 
multipolygons as geometric constructs can ignore the higher level relations.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Giant river multipolygons

[Malcolm Herring]

On 28/01/2013 16:26, Tobias Knerr wrote:

  I'd like to hear your opinions.


+1
As a developer of both editing and rendering software, such data 
structures are troublesome. I dislike multipolygons with multiple 
disjunct outers both as a mapper & as a developer. I have had to abandon 
edits when warned that I was about to break a multipolygon with 999 
other members. How can one know what that structure is if one cannot see 
it all in a feasible JOSM download?



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] non-trivial color schemes

[Malcolm Herring]

PS: We even have that rare thing - documentation!

http://wiki.openstreetmap.org/wiki/OpenSeaMap/Colours


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] non-trivial color schemes

[Malcolm Herring]

On 18/12/2012 21:16, Frederik Ramm wrote:

OpenSeaMap have tons of funny tags for colour-coded buoys, and they even
have an editor plugin for JOSM where you can visually compile a buoy
layout and have the plugin set the right tags - maybe some of their work
can be applied here.


Indeed we do! Objects that have variable colour schemes have a pair of 
attribute tags in the form "...:colour=" and 
"...:colour_pattern=


Examples of pattern values are horizontal(stripes), vertical, diagonal, 
squared, border, etc.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clean-up the seamark landmark tags on the wiki (and perhaps later in the db)

[Malcolm Herring]

On 23/11/2012 10:24, Pieren wrote:

"landuse=cemetery" + "landmark=cemetery" + "seamark=landmark" +
"seamark:type=landmark" + "seamark:landmark:category = cemetery"


As I said, those latter two tags would only appear on cemeteries that 
can be seen from the water and can be used as navigational markers. We 
need these differentiated tags for the various marine navigation 
specific renderers & other applications.


It is the second two tags that should be considered for deprecation, as 
they belong an abandoned tagging proposal.


We do not ask that our tags be applied by the wider mapping community, 
only that where they are found, not to delete them!



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clean-up the seamark landmark tags on the wiki (and perhaps later in the db)

[Malcolm Herring]

Any tag whose key is in the form "seamark:" is from the OpenSeaMap 
tagging scheme. Landmarks that bear these tags are features that can be 
seen from the sea or river and can be usefully used for navigational 
purposes. This is additional information, not duplicate information, so 
they may well co-exist with the conventional OSM tags for whatever type 
of map feature the object is.


It is true that our tagging scheme is not well documented. This is being 
addressed, but as always, this task gets a low priority. In the case of 
landmarks, there is some documentation: 
http://wiki.openstreetmap.org/wiki/OpenSeaMap/Landmarks


Note that there are some tags with the key "seamark". These are not 
OpenSeaMap tags, but belong to another tagging scheme that was proposed 
about 3 years ago, but the proposal was abandoned before any voting took 
place.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fuel, additional tags

[Malcolm Herring]

On 13/11/2012 17:02, Martin Koppenhoefer wrote:

The tagging scheme proposed there doesn't really make sense in the
contest of OSM.


"in the context of OSM" is the operative condition, that is why I 
pointed out that the tags I detailed were OpenSeaMap tags.




1. These are not seamarks.


"seamark:" is the OpenSeaMap prefix for any marine navigation object 
that appears in the IHO object catalogue. That does not cover only 
markers, but any object that can appear on a marine chart.



2. the tagging scheme seems unnecessarily complicated


Yes it is, but it was invented by the IHO, not us. We merely transcribed 
it into OSM format tags.



3. most of the objects already have a nice short tag, instead of


There are many objects that are of interest to both StreetMap and SeaMap 
consumers. In these cases, tags from both schemes would be used.




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fuel, additional tags

[Malcolm Herring]

On 12/11/2012 16:55, Janko Mihelić wrote:

First, I think we have no tags for a fuel station that boats can use.
Taginfo says we have a tag harbour:fuel:diesel used 66 times, but it
doesn't look quite right to me. This tag is maybe used to tag a harbour
that has a fuel station.
We have just one tag fuel:marine=yes which looks right to me. Can we put
that one in the wiki?


Janko, as to your first question, a suitable tag is that used by OpenSeaMap:

seamark:type=small_craft_facility
seamark:small_craft_facility:category=fuel_station

This tag is applied to a node at the actual location of the fuel 
station, rather than the harbour:fuel:diesel tag, which merely lists a 
facility within a harbour area, but does not indicate the location of 
the fuel station.


See: http://wiki.openstreetmap.org/wiki/OpenSeaMap/Small_Craft_Facilities


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fuel, additional tags

[Malcolm Herring]

On 12/11/2012 19:27, Jo wrote:

The dye added is not the common denominator. We need the British term
for the tax break status of it.


Two common terms in use are: "marked diesel" and "agricultural diesel".


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging