Re: [Tagging] Bad mapping in Pointe Noire Africa?

2018-12-15 Thread Kevin Kenny
On Sat, Dec 15, 2018 at 8:12 PM Warin <> wrote:
> I came across a lot of sport=null  .. and found it in Pointe Noire,some
> 18,000?
> Looks like there are a few other *=null there too.

'null' usually indicates a botched import from a database that had
fields with missing values.

Tagging mailing list

Re: [Tagging] Can OSM become a geospatial database?

2018-12-09 Thread Kevin Kenny
On Sun, Dec 9, 2018 at 6:19 PM EthnicFood IsGreat
> > Most probably you would not want to look for all "brooks", because
> > "brook" is just one of multiple words that mean the same thing. There is
> > no semantic difference between a "brook" and a "stream" in general
> > nowadays. Its just that in different regions of the english speaking
> > world different words were commonly used, and people in America used
> > whatever word they were familiar with.
> So true.

Yes, indeed. In my part of the world, common words in the name of a
watercourse include:

river - Usually but not always a major river: the Hutchinson River or
Bronx River are pretty small over most of their length. Can also be a
tidal channel (East River, Harlem River). A major river will usually
keep its name even in the estuarine environment. (Hudson River
salinity varies but is usually still salt in Tarrytown in a dry
season, and the river is tidal as far as Troy.) To the north of me
there are many small streams named 'river' because English conquerors
translated French 'rivière', which refers to the order of a
watercourse and not its size (a 'fleuve' flows to the sea, a 'rivière'
to fresh water).

creek - can be any size from a trickle to a sizable river like the
Schoharie Creek, or can be a tidal estuary.

kill - can be any size from a trickle to a mid-size river (Roeliff
Janssen Kill, Normanskill, Catskill, Kaaterskill, Sawkill, etc.), or
can be a tidal estuary (Arthur Kill, Kill van Kull). Usually named by
Dutch settlers.

brook - Usually small, will sometimes still cross over to 'river' by
OSM's definition. Often named by Dutch settlers, but the English also
used 'brook' to translate French 'ruisseau'.

run - Usually small.

stream - Usually small.

fork - Any size, generally a tributary of a larger watercourse.

branch - Any size, generally a tributary of a larger watercourse.
(Farther south, 'branch' can mean any small stream.)

inlet, outlet - Used for (usually small) watercourses that are short
and connect a lake or pond to another waterbody.

The fact that the name of a watercourse indicates any one of these
words most emphatically does NOT provide any reliable indication about
its type, order, size or variablilty.  The Schoharie Creek is a major
river with several hydroelectric power stations and reservoirs along
its length. The Marble River up in Franklin County is only a few km
long, and I can wade or rock-hop it pretty much anywhere along its

And they are NOT misnamed. Sorry, but English doesn't work that way.
Putting a different word in the 'name' field of any of these
watercourses would be 100% wrong. 'Schoharie Creek' can be called 'the
Schoharie' colloquially when it's unambiguous, but call it 'Schoharie
Brook' and people will look at you as if you have two heads. The
Normanskill isn't the 'Normanskill Creek' or 'Normanskill River', nor
is it the 'Norman Creek' or 'Norman River' - its name is what it is.

You cannot expect English to follow the grammatical rules of Russian.

Tagging mailing list

Re: [Tagging] Can OSM become a geospacial database?

2018-12-06 Thread Kevin Kenny
On Thu, Dec 6, 2018 at 10:58 AM Eugene Podshivalov 

> Let's look into some other examples.
> Settlements are supposed to be defined with
> place=city/town/village/hamlet/isolated_dwelling tags. The value depends on
> the size of the settlement.
> But in Belarus for example we call our settlements "город" (can be city or
> town), "городской посёлок" (can be town or village),
> "посёлок"/"деревня"/"хутор" (can be village or hamlet or isolated_dwelling).
> When people use the maps created form OSM database they don't care about
> the generic OSM categorization of settlements. They need their local
> category names.
> So what tag should be put those local category names in?
Several thoughts.

If it's something that people usually use in referring to the place, put it
in the name. So 'Nizhny Novgorod' would be named thus (sorry, I don't have
the time to try to enter Cyrillic on a US keyboard).

If it refers to an administrative entity, put an appropriate level in the

Where I live, the formal designation of a place usually fails to match the
OSM definition. We have formal 'hamlet's that have 6 inhabitants, and
chartered cities with only a few hundred. We use boundary=administrative
with an appropriate admin_level (and I've been lobbying for
administrative:entity to give a word for the legal designation: county,
borough, city, township, village, hamlet, ward, precinct, community
district, ... but that hasn't gotten any significant traction yet). The
'admin_level' is not strictly hierarchical here, because our system for
drawing administrative boundaries is, "there's no system: deal with it!"
The OSM definition is useful for mapping - deciding at what level to render
the name and in how big a font, for instance. Few people around here
actually care when using a map what formal political organization the place
has. Whether the community I grew up in was a Hamlet or a Village made very
little practical difference. You'd have a different set of local
politicians, and the cops might work for the county instead of the town,
but the type of place was clearly much less important than the borders of
the place.

If it's a question about the common name rather than the formal name,
that's usually dealt with by name_1, etc. That way, the city called "New
York" can be disambiguated, "New York City" (informal, very commonly used
to make it clear that it's New York City and not New York State), "The City
of New York" (what appears on most of its legal papers), "The City of
Greater New York" (the way it's styled in its charter).

If it's neither a component of the name of the place nor a formal
designation of a political boundary, can you explain more why it's
important? Is it immediately obvious in the field that one thing is a
'gorod' and another is a 'gorodskoy posyolok,' while a third is a
'perevnya?' If so, what is the difference? What's the problem we're trying
to solve?
Tagging mailing list

Re: [Tagging] Can OSM become a geospacial database?

2018-12-06 Thread Kevin Kenny
On Thu, Dec 6, 2018 at 9:31 AM Sergio Manzi  wrote:

> That's what I'm often hearing, and not only from you, but have a look at
> wiki page about the *craft *key [1
> ], as in there I can read:
> "*You are free to use values that match your needs as a mapper and your
> local or country environment, culture and language. If using the English
> language, please use the singular form, e.g. carpenter not carpenters or
> carpenter's.*"
> From the above I get:
>1. A recognition that sometimes English terms are not fit to convey a
>culture-specific concept.
>2. I can use terms that are not part of the English language if they
>are needed to convey such concepts.
> Right. But please don't resort to local-language words for terms that do
have a satisfactory UK-English equivalent. Don't use craft=menuiscier in
French when 'carpenter' is a serviceable English word. And please wikify
your choices.
Tagging mailing list

Re: [Tagging] antenna use key to replace some of the antenna type

2018-11-30 Thread Kevin Kenny
On Fri, Nov 30, 2018 at 5:50 PM Warin <> wrote:

> Unfortunately mappers will map things as they see them. And some will want
> to add more and more detail.
> Keeping that detail in some order is what I am on about here. At present
> it is all going into antenna:type, system, polarization, configuration ...
> everything ..
> I'd prefer some more organisation than simply lumping it all together
> under one tag.

Equally on point, though, is that we need a way to keep things simple for
the mapper armed with only a pair of eyeballs, some survey equipment such
as a phone-GPS, and common knowledge of the world. I don't think we devote
enough effort to ensuring that such a person can still map the basics of
what's there on the ground. I surely don't want anyone to have to do
research before even roughing something in.
Tagging mailing list

Re: [Tagging] Neighborhood Gateway Signs?

2018-11-30 Thread Kevin Kenny
On Fri, Nov 30, 2018 at 5:59 PM Graeme Fitzpatrick 

> That sort of works, but do we need something to say it's a big rock, or
>> cement column?
> The 'description' tag, perhaps? Things eventually get to the point where
even the obsessive classifiers on this list might as well admit that even
if they do introduce a taxonomy, it is likely that no data consumer will
use it.
Tagging mailing list

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-27 Thread Kevin Kenny

On 11/26/18 6:35 PM, Clifford Snow wrote:
I can't speak for other countries so I'll limit my comments to the US. 
As Kevin Kenny commented, tribes in the US are recognized as domestic 
dependent nations.  But from there it gets messy. They can set their 
own sales tax separate from the state and have their own courts. Yet 
in North Dakota, the state determines voting requirements. For this 
reason I don't think admin_level works very well.

1. admin_level doesn't work in the US, period.

2. There's no good answer, but admin_level=3 might be a good compromise.

3. Occasionally the First Nations function as countries.

4. Just what the First Nations are is a political question with about 
four hundred years of bloody history. Occasional bloodshed continues to 
this day. We're not going to come up with a satisfactory answer here.


There is no administrative unit in the US - except or the states and 
perhaps the counties (which not all states have) for which admin_level 
really works well. Counties in New York can set their own sales tax, and 
so can chartered Cities, two of which cross county lines. Landowners in 
a Village owe property tax to both the Village and the Town - and maybe 
a sixth of the Villages are in more than one Town. It's *all* messy.

And that's without accounting for special administrative districts for 
schools, libraries, police, garbage, sewers, fire brigades, water 
supply, ... New York has dozens of different flavors, none of which is 
constrained to the boundaries of anything else, and all of them have 
elected [or state-appointed] officials and the power to tax. We've never 
tried to settle how to tag these in OSM - we simply don't map the 
limited-purpose admin areas such as school districts.

The Europeans think the US system is totally insane, but it mostly 
works. In any case, it has to be a case of "we map what we have." Too 
often, what we hear from some individuals on this list is not very far 
removed from, "the tagging model is fine; fix your country!" That, of 
course, is not really an option that's available to us in the near future.


As far as 'aboriginal lands' go, I'd be happy with either 
boundary=administrative or else a new sui generis boundary type. If it 
is to be 'administrative', I'd argue for the otherwise unused 
'admin-level' of 3, a compromise among a set of political alternatives 
that range from '2' (a country whose rights happen to be denied) to 
nothing at all (an illegitimate country issuing 'fantasy passports' with 
no more legal existence than self-proclaimed 'micro-nations'). Like all 
compromises, it will satisfy nobody, but at least acknowledge that a 
diversity of opinion exists.


The larger among the First Nations surely have a messy status.

Some issue passports. The Cayuga statesman Levi General Deskaheh 
traveled to Great Britain in 1917 and Geneva in 1923 on a Haudenosaunee 
passport to plead for recognition of his people by the British crown and 
at the League of Nations. As recently as 2018, athletes from the 
Haudenosaunee Confederacy traveled on Haundenosaunee passports to 
compete in world-level events. Israel accepted the Haudenosaunee 
passport for their admission, and Canada, while not recognizing tribal 
sovereignty, offered assurances that the competitors would be 
repatriated. The US players crossed the US-Canada border at Akwesasne, 
where a US-UK treaty that allows FIrst Nations natives to pass has been 
in force - although often violated - since 1792. The US, Canada, and the 
Schengen nations, however, emphatically do *not* recognize the 
Haudenosaunee authority to issue passports.


Referring to the Haudenosaunee as a 'tribe' is ... strange. The Six 
Nations are a federal republic with a constitution which they adopted in 
1142.  unwritten but widely memorized, since it has religious 
significance. Despite the oral nature of the history, it can be dated 
accurately because of an account of a solar eclipse. There is ample 
evidence that it was functioning as a republic in 1603, when Champlain 
first encountered them, and they were still functioning as such in 1722, 
when the Tuscarora Nation was admitted as a sixth member nation of the 
Haudenosaunee Confederacy. The Confederacy was, in some ways, the model 
for the US system of separate Federal and State sovereignty - and the 
Framers of the Constitution were well aware of it.

North Dakota, as you mention, is an odd case. It does not 'determine' 
the voting requirements for citizens of the dependent nations. It (along 
with fifteen other states) has power delegated to it by Congress to 
enforce Federal and tribal law on the reservations, and as such, is 
responsible for upholding the rights that the tribes have determined. 
It's an executive, not a legislative authority. In th The local sheriff, 
the tribal police, the Bureau of Indian Affairs, and the FBI all have 
jurisdiction to enforce Federal and tribal law. The resulting 

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-26 Thread Kevin Kenny
On Sat, Nov 24, 2018 at 7:40 PM Alan McConchie 

> Should we use the single tag boundary=aboriginal_lands for these areas? Or
> should we deprecate that tag (in other words, reject the proposal) and
> instead use boundary=protected_area + protect_class=24?

I really don't like overloading 'protected area' for what, in my region, is
a unit of government.

The First Nations' lands near me are, for the most part, recognized as
'domestic dependent nations' and, if we wanted to be formally correct,
would most likely come in at admin_level=3. (admin_level is rather a mess
in the US, because we have things that aren't strictly hierarchical at all
levels - we have a First Nations treaty land (established by the Jay Treaty
of 1794) that crosses an international border, and others that span state
lines, just as we have cities across county lines, villages across township
lines and so on.

In my state, no First Nations land is within any township - towns, cities,
and "Indian Reservations" are all disjoint. The "Indian Reservations" have
home rule for many matters.

I'd be fine with boundary=administrative or a sui generis
boundary=aboriginal_lands, but 'protected_area' is horrible.
Tagging mailing list

Re: [Tagging] [OSM-talk-be] identifier in ref:xOperatorx=y0yyyy to url=

2018-11-18 Thread Kevin Kenny
On Sun, Nov 18, 2018 at 11:16 AM André Pirard 

> Jakka's point is not that "url" is used but that it could be wanted and
> that this usage would prevent it.
> To prevent the "first jumping on it owns it" practice, the good move would
> be to consider that anything:url is *officially* an URL.
> "being officially" meaning principally that listings make it a clickable
> link.
> Even though any URL can be recognized inside any text and made clickable.
> But I've had problems suggesting to make multiple tags containing URLs
> clickable.
> The answer was: "the URL tag exists already" ;-)

For whatever it's worth (probably not much), when I imported the New York
City DEP recreation lands data, most of the facilities had multiple URL's -
the main URL for the facility, the URL for the facility's official map, the
URL for the site where permits can be obtained (if permits are required)...

At the time, JOSM warned me about 'url' and proffered 'website' in its
place, so I went with that in place of 'url'. For the secondary sites (map,
permit service, ...) I used 'website:map', 'website:permit', etc.  The
tools appear to recognize it - at least when I call up a place like, the URL's render
appropriately as links. I may have got it all wrong, but nobody corrected
me on talk-us or imports at the time.
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Kevin Kenny
On Sat, Nov 17, 2018 at 3:36 PM Paul Allen  wrote:

> You point out that neither a new polygon that shares nodes with coastline
> ways nor a complex
> relationship are going to play nicely with the toolchain.  Being a bear of
> little brain, and lazy to
> boot, my first thought would be a crude polygon approximating the
> coastline.  It would have few
> enough nodes that it would be renderable but approximate the coastline
> sufficiently well for label
> placement.  Provided the carto didn't render the bay in a different colour
> or with a visible border it
> would handle label placement nicely (particularly if the renderer's
> placement algorithms
> improved in the future) without looking fugly.  I must be wrong about
> this, though, because I
> recall an earlier post in this thread pointing out where somebody had done
> something very like
> that and denounced it as a crime against humanity.

That's what I meant when I discussed 'generalizing' the way.
'Generalization' is a GIS-speak term for reducing point count and
resolution to make an object suitable for rendering at larger scale.

So all that appears to leave is a node with sub-tags of bay=small,
> bay=intermediate, bay=large and
> bay=supersize to control the size of the label whilst the mapper controls
> the position of the label by
> guessing where the node ought to go.  I still like a polygon even if the
> water in the bay looks no
> different from the ocean because using the query tool on the polygon will
> bring up an approximation
> to the extent of the bay.

It is sounding as if Frederik and Christoph are willing to tolerate limited
experiments as long as we mostly don't damage the coastline, and keep our
areas small enough not to break the toolchain. I'm satisfied with that as
an answer for now. If using areas has the advantages that you and I think
it does, then it'll win out over time. If it has the difficulties that
Frederik and Christoph fear, then mappers won't adopt it and the discussion
will be moot.

And I surely sympathize with their woes about managing large objects! I've
had to repair ones like Lake Huron (relation 1205151, but please don't
overload the server by trying to fetch it!) a time or two, myself, and it's
painful, what with the server timeouts and all. (There was a serious
proposal floated at one point to make the Great Lakes 'natural=coastline',
for just that reason, but I seem to recall that it foundered on topology.
The only way to handle it would have been to extend the coastline all the
way up the St. Lawrence, Niagara, Detroit, St. Clair, Mackinac and St.
Mary's Rivers, and make all the islands in the Great Lakes 'coastline' as
well - effectively inverting the topology of everything in contact with the

So for the moment, I'll confine any experiments to objects the size of
Jamaica Bay, while leaving Hudson Bay or the Gulf of Mexico, or even the
Long Island Sound, to a later time.

I'm convinced that sooner or later we will need a better general solution
than just placing a node - as I said, I'd really like a paper map of
Helsinki or Tallinn to label the Gulf of Finland. But I don't yet have
really good ideas about how to upgrade the technology to get there with
large objects - a few half-baked ones, but I'm rather a long way from
trying them yet.
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Kevin Kenny
On Sat, Nov 17, 2018 at 1:45 PM Christoph Hormann  wrote:

> As we say in German: Umgekehrt wird ein Schuh draus.

We seem to be up against a cultural difference. English has proverbs like
'don't throw the baby out with the bath water,' and 'the perfect is the
enemy of the good.'
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Kevin Kenny
On Sat, Nov 17, 2018 at 6:29 AM Frederik Ramm  wrote:

> Another pet peeve of mine is a dislike of what I call "relation mania",
> where we have land boundaries that can easily be part of 20 different
> relations on different admin levels and other boundary types. It's bad
> enough on land, and makes editing harder for everyone;

You're welcome to this particular opinion in your personal capacity and are
free to argue the point as passionately as you care to.

When you have your DWG hat on, might I ask you to acknowledge that there is
a diversity of opinion in the community on this topic? A minority of users
(including myself), whose number appears to be growing, find that sharing
boundary ways among multipolygons creates a structure that actually is
easier to enter, edit and maintain than the one that appears from multiple
retraced ways over the same nodes, or worse, independently traced ways that
are approximating the same boundary in the field. Land use, land cover, and
cadastral boundaries (such as administrative regions) in particular appear
to be well served by this sort of topological approach.

Today, the difficulty seems to depend partly on the editor in use. JOSM and
Meerkartor handle it quite well indeed; iD and Potlatch still struggle -
and that may be part of the reason behind the "it makes editing harder"
argument. (There's a chicken-and-egg situation there too: some  edittors
support it badly, so people argue that it shouldn't be done, so those
editors continue to support it badly.) If the idea becomes more relevant,
the tools will improve.

Given that there is some history of arbitrary decisions in this particular
arena, may I make the plea in advance that the technique not be summarily
suppressed until there is more experience with how it works out in the
places where it's being tried? I know you've managed to exercise such
restraint in the past; you've personally disagreed with at least one import
that I've conducted and nevertheless allowed it to stand.

This request also has nothing to do with relations that are large enough to
break the tools. I'm confining my request here to features that are
relatively small in extent - perhaps up to a few tens of km on a side. The
larger of them would be represented as multipolygons in any case because
their bounding ways have too many nodes to be handled gracefully.
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Kevin Kenny
On Sat, Nov 17, 2018 at 10:23 AM Paul Allen  wrote:

> On Sat, Nov 17, 2018 at 11:29 AM Frederik Ramm 
> wrote:
>> I do agree that while we should not "map for the renderer"
> I would modify that a little.  We shouldn't LIE for the renderer.  Given
> two, equally valid (documented,
> accepted, supported) tagging schemes we are at liberty to choose which to
> use, and our choice may
> be influenced by the rendition of one or more renderers.  But that's a
> side-issue.


The purpose most mappers have, when deciding to include an object, is that
the object should be rendered somewhere. I don't say here, 'rendered in
OSM-Carto', I say 'rendered somewhere'. I'm entirely willing to do my own
custom rendering for objects of special interest.

But, when I've asked questions of the form, "how can I most effectively tag
objects of type A from objects of type B, because I wish to render them
differently on my own maps?" (Example: the access=permit kerfuffle), I've
repeatedly been met with an argument that I'm tagging for the renderer.  It
is not 'tagging for the renderer' to make the observation that no
conceivable renderer can make a decision based on data that are not on the

The discussion of indefinite objects falls in the same category in my mind.
We shouldn't have to discard what is known or defined about an object
because some other part of the object is unknown or indefinite. We can't
map what is known if we've thrown it away. I don't want to throw away St.
Lawrence County because nobody has ever surveyed a line through the swamps
of the St. Regis basin, and I likewise don't want to throw away Jamaica Bay
(or for that matter, the Gulf or Bothnia) because we don't have a 100%
agreed-on field-verifiable bright line across their mouths. I recognize
that the Gulf of Bothnia may fall afoul of technological limitations, and
I've conceded that point, but in cases where we won't cause widespread
breakage, it surely makes sense to do what can be done with the imperfect
information at our disposal!
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Kevin Kenny
On Sat, Nov 17, 2018 at 6:29 AM Frederik Ramm  wrote:
[longish observation blaming OSM Carto for the fact that people
were coming to map bays as areas...]

> So, long story short, a couple of "my" maps suddenly started to show
> ugly dark-blue patches e.g. across the bay of Biscay, or the Gulf of
> Bothnia. That's how I noticed and investigated what was happening, and I
> found that Daniel had added the Gulf of Bothnia polygon to accompany the
> newly-introduced OSM-Carto feature of rendering bay names depending on
> the size of the area.

In my case, OSM Carto had very little to do with it.

As I discussed in earlier messages, my motivation is that I render a fair
number of maps, moslty for my own use and my friends, on actual dead-trees
paper (or more often Tyvek, which I suppose you could call 'dead-dinosaurs
paper'). I do want my maps to show the names of significant geographic
features that appear on them, even if the region of interest of the paper
map includes only a small portion of a large feature. I could not figure
out a way to do that without defining area features as areas. Doing so runs
afoul of Christoph's pronouncement that no area features should be mapped
as areas unless every metre of a border was field-verifiable.

I found that pronouncement quite disturbing, since I live in a region where
there are significant administrative regions whose borders are indefinite.
(I recognize that there's a cultural difference here: the chaotic American
approach to such matters is, "we'll survey it if it ever becomes important
enough that someone will pay for the survey." Where is the precise boundary
in the swamps of the St. Regis River basin? Nobody much cares. The county
line is surveyed and monumented where people do care.) If that
pronouncement were carried out to the letter, a couple of counties in my
part of the world would have to be reduced to nodes.

In the case of an ugly dark-blue patch over the Gulf of Bothnia or the Bay
of Biscay, I'd definitely have directed my annoyance at the renderer. When
I've done my own rendering, I've never distinguished inland from ocean
waters by colour - precisely because it unduly emphasizes the arbitrary
lines between them, which occur at every river mouth, estuary, and yes, bay.

Whether OSM-Carto encourages, discourages or is neutral toward the style in
question is something that is of no concern to me.

 he went through the time-consuming
> exercise of combining more than 1600 coastline pieces into one huge
> polygon which is difficult to handle for data processors and editors

I have found that when anyone is advancing an argument with the word 'just'
in it, that the word is demanding a suspension of disbelief, and the
position would be more accurately stated without it. Deferring the
discussion of data processing to a later paragraph, let me translate. _He
went through that difficult and time-consuming exercise to place a label._
Can you see how that sounds different? It is not an arrogant assertion that
your assessment of the importance of the task is more valid than his. It
leaves open the possibility that the presence of the label was important
enough to him that it was worth going through that work to allow for it.

Objects in the real world have names. One of the functions of a map is to
inform its users of the names of the objects that it displays. Surely maps
have many other functions, but connecting the displayed objects to human
language and the human sense of orientation is one of them. It is hard to
find a map, anywhere, that does not have labels for named objects because
that is a critically important part of what a map does.

In my particular use case, a node label would be useless to me. I do render
large-scale maps that often contain a small piece of a much larger objects.
Having a node with the object's name somewhere far beyond the boundaries of
the region of interest is worthless to me. That is why I favour carrying
area features as areas rather than nodes, always. (It also gives a more
sophisticated renderer than Mapnik many more options for resolving
conflicting labels.)

Maps from before the OSM era did this pretty much universally.  Returning
to my Jamaica Bay example, shows the meeting
point of four sheets in the old USGS 7.5-minute topographic series. You'll
see that all four of the sheets have labeled 'JAMAICA BAY', even though the
quadrangle to the northwest has only a little triangle of it in one corner
and the one to the southwest has only a narrow strip along its eastern
margin. That's because it is a locally important feature - and assigning it
a name truly is important. It is the feature that dominates the landscape
of those who live by it. If I were to be producing almost any map of that
area by hand methods, the ocean, the bay and the airport are surely the
first three features I'd sketch in, and the labels I would least want to

It is only a matter of 

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-16 Thread Kevin Kenny
On Fri, Nov 16, 2018 at 8:01 PM Christoph Hormann  wrote:

> We all know you think bays and straits should best be mapped with
> polygons and that it is a positive thing to steer mappers to doing that
> (which by the way is against the goals of OSM-Carto even if your
> opinion on this has merit).  You can try to justify that all you want -
> this does not change anything about the argument i gave against it -
> that the polygon drawing almost never adds any verifiable information
> on the geographic reality compared to a node or a linear way
> representation.
> I know i will not change your opinion on this - countless non-successful
> discussions with you on much clearer and simpler matters have shown me
> that.  I can just hope most mappers will emancipate themselves from
> this and not invest their time and energy in mapping and maintining
> polygon mazes over coastal waters.

I think that I need to reduce the cases to something more concrete in order
to follow your argument that nodes are perfectly adequate to convey the
extent of bays, straits, estuaries and similar features well enough to map
them  - particularly on maps that have a constrained region of interest.

I'm fairly good at both mapping and rendering, and quite good indeed with
the mathematics and programming - but somehow I'm still not following how
to implement your suggestions. I am willing to be convinced, but so far you
have failed to convince me.

Let's consider a map that I actually would like someday to produce: a
large-scale map of the waterfront community of Inwood, New York. I'll want to have it on a
sheet of A4 or US Letter paper. The extents of the map will therefore
likely be west into the water, perhaps about as far as the jetty at the
airport; east nearly to the railroad station in Cedarhurst, south to
about the station in Far Rockaway, and north perhaps to the bridge in
Meadowmere Park.

By far the most significant label that must be placed on the map, given the
waterfront nature of the community, is Jamaica Bay. Only a small portion of
the main bay would appear within that box, but much of the west edge of
such a map would be the water of the bay. Jamaica Bay can be seen in its
entirety by zooming back to level 12 or 13 and panning the map to the west
- it is the large oval area from Inwood out to the Atlantic Ocean.

If the bay were an area feature, I would be able to place a label on the
area feature that is created by intersecting its extent with the region of
interest. But, because of indefinite boundaries, the use of an area feature
is denied to me.

Assume that I am willing to be flexible about the deduced extent of the bay
where it is indefinite. I do not care, for instance, whether its mouth is
placed at the narrowest part of the entrance, near the Marine Parkway
Bridge, or at the traditional start at the imaginary line that connects the
tip of the jetty that protrudes from Breezy Point to the tip of the pier at
Coney Island to its north.  I similarly don't necessarily demand absolute
precision about the boundary between Jamaica Bay and the back bays such as
the Head of Bay, Norton Basin, Motts Basin, Motts Creek, Hook Creek or
Thurston Basin - any reasonable answer is fine.

So - problem #1:  What point, line or area features do I need to place in
the OSM data base to determine that the water in question is part of
Jamaica Bay so that I can label it on that map? Given those features, what
is the computational pathway that can inform a renderer that such a label
needs to be placed?

I am not assuming that OSM-Carto, Mapnik, or indeed any other existing
rendering chain contains a complete implementation of all the logic needed.
Instead, I am seeking help to develop a detailed specification. If this,
and the questions that I plan to follow up with, are answerable in the data
model that you envision, then this sort of thing will have to be
programmed. I'm willing to try my hand at such an implementation and do any
reasonable amount of analysis and programming. I still lack a clear vision
of how to proceed - although having a clear description from you of the
objects that are required in the database may help be a start at that.

Share the insight that you claim to have that I lack. Convert me to your
way of thinking.  If you are in possession of such deep understanding, it
will surely not be difficult to demonstrate by a single example how you
solve the problem.

I anticipate answers that deflect the question. Because of that, I state:

If I cannot be given an answer to such a concrete problem, I will not
accept that the reason is that I am too stupid or unskilled to understand
your superior wisdom. Nor will I accept a bald assertion that I am asking
the wrong question. Producing a conventional map on a sheet of paper is a
reasonable thing to want to do even in our digital age: as I stated before,
a sheet of paper and a magnetic compass never have dead batteries, and

Re: [Tagging] Neighborhood Gateway Signs?

2018-11-15 Thread Kevin Kenny
On Thu, Nov 15, 2018 at 10:44 PM Joseph Eisenberg <> wrote:

> Please look at the examples in Indonesia. They are not sculptures or
> artwork. And they are erected by the very local government at the
> neighborhood level. The large sculptural signs in San Diego are rather
> artistic, but they are put up by the government or with government approval
> at least, because they span the street.

The local government is often the patron of artwork. There are towns and
villages near me that have a fair amount of government-erected public
sculpture that is there simply to express civic pride or entertain
visitors. It's for you to decide whether the objects that you wish to map
are there to decorate or to direct. I don't think the fact that a
government sponsored them necessarily determines that.

In the case I gave of the Northville-Placid Trail arch, it was erected
intentionally for tourism - so that hikers starting or finishing the trek
could have a spot for a photo-op or some other ceremony to mark their
aspiration or accomplishment. It's a much better site for such an emotional
moment than the former terminus, which was a rather nondescript road
intersection in the middle of the village. I had previously walked the
entire length of the trail as it then stood, but I felt a much greater
sense of completion when I came back a couple of months later, hiked the
newly-opened southernmost section and strode through the arch. "Now I can
truly say I've done the whole thing!'

In the cases I gave of gates at the entrance to American subdivisions,
their purpose is chiefly to advertise the developer, and they tend to fall
into disrepair once all the houses in the subdivision are sold. Once in a
while, a village or a residents' association might spruce them up a bit.

In the case of the Portland Chinatown gate, I really more or less saw the
purpose as shouting, "Welcome, tourists! Here's Chinatown! We're proud of
the place! Please come in and spend lots of money!" (Which is a reasonably
legitimate reason for a government to erect such an artifact - it's called
promoting the local economy.,)

Another consideration is that these are overhead “barriers” for tall
> vehicles. A full-size truck / lorry can fit under the American ones, but
> not under the gateway signs in Indonesia, so these are significant for
> routing.

Then by all means put maxheight=* on the ways going under them! I believe
that lorry routers are supposed to honour that tag.
Tagging mailing list

Re: [Tagging] Neighborhood Gateway Signs?

2018-11-15 Thread Kevin Kenny
On Thu, Nov 15, 2018 at 9:45 PM Paul Johnson  wrote:

> On Thu, Nov 15, 2018 at 8:35 PM Kevin Kenny 
> wrote:
>> On Thu, Nov 15, 2018 at 8:48 PM Joseph Eisenberg <
>>> wrote:
>>> Here in Indonesia it is very common for neighbors to build sign over
>>> the main entrance to their neighborhood, with the name of the
>>> neighborhood on top and some other info on the two columns supporting
>>> the sign.
>> For all the examples you give, they're not very useful as signs in terms
>> of giving directions, and they have a more ceremonial role. I wonder if
>> what we're dealing with isn't a public sculpture.
>  I can only speak of Tulsa and Portland examples as those are the two
> metros where I've seen these most prolifically, though if you look on the
> back of many stop signs or the left side of the street after an
> intersection at the edge of a district (neighborhood), there will be a
> round sign (probably using a blank W10-1) with the district's logo.  These
> signs line the perimeter of the district, making it possible to form the
> administrative boundary of the district.

Interesting, but not exactly the ceremonial gateway to a neighbourhood.
Where I grew up, there are a lot of ceremonial gateposts, but less
elaborate, more like what you see in .
Come to think of it, the subdivision where I live now still has a couple of
its signs   There was one village near
where I grew up that had actual, functioning gates on the roads going in
and out - for an unknown reason, it wasn't a gated community. They're long
gone, but you can see where they were in spots like .

I've not mapped any of these gateways; the most I've done is to map the
boundary of the subdivision and tag it landuse=residential name=Orchard Park

Georgia puts its county road numbers inconspicuously on vertical green
signs - shaped a lot like many states' mileposts, and maybe they are
painted on the same stock as their freeway mileposts - on the back of STOP

But I still think that the gateways that Joseph describes are most likely
public sculptures rather than useful boundary markers - particularly if
they are unofficial and erected by the residents.
Tagging mailing list

Re: [Tagging] Neighborhood Gateway Signs?

2018-11-15 Thread Kevin Kenny
On Thu, Nov 15, 2018 at 8:48 PM Joseph Eisenberg 

> Here in Indonesia it is very common for neighbors to build sign over
> the main entrance to their neighborhood, with the name of the
> neighborhood on top and some other info on the two columns supporting
> the sign.

For all the examples you give, they're not very useful as signs in terms of
giving directions, and they have a more ceremonial role. I wonder if what
we're dealing with isn't a public sculpture.

That's how I treated this one

which marks the southern terminus of the Northville-Placid Trail (a 222-km
hiking route through the Adirondack Mountains of New York).
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-15 Thread Kevin Kenny
On Thu, Nov 15, 2018 at 3:02 PM Christoph Hormann  wrote:

> > Even in that extreme example, having the spatial extent adds value.
> Data of subjective value for a specific application (like low quality
> label rendering) - yes, obviously.  Meaningful additional information
> about the verifiable geography - no, i don't think so.

By 'low quality', I presume you mean 'of a quality that can be achieved
algorithmically rather than by manual label placement by a skilled
cartographer?' Otherwise, what's your approach to higher quality?

> What you usually will want to start with is finding the closest point on
> the coastline.  You might not want to use the original coastline data
> but pre-process it to some extent to for example eliminate small
> isolated islands.
> If you just want to do a primitive importance rating based point label
> rendering like OSM-Carto you will then just take all coastlines within
> something like 3-5 times that distance and make a bay size assessment
> based on that - your choice how fancy you want to make this.  Simplest
> version is to use the distance right away but you can easily make this
> a bit more robust.
> If you actually want to place a label dynamically procedure will depend
> a lot on the style of label you want to use - horizontal single line,
> multi-line, rotated, curved - font size scaled or characters spaced
> according to the extent of the label.  This part can be somewhat akward
> and inefficient because common spatial database systems are not
> specifically designed for this kind of task. What you need to do is
> essentially to 'probe' the coastline environment and determine the
> extent of the bay and where the desired label best fits in there.

I can see how that approach might sort of work in some cases, but it
strikes me as rather brittle.  A node anywhere in the middle of the Sea of
Cortez or the Gulf of Aqaba will be close enough to the nearest shoreline
that measuring off 3-5 times the distance will still not span the length of
the waterbody, meaning that identification of it as an area feature will
still be less than what we'd want.  A large-scale map of Eilat  would still
have a really difficult time - even considering the larger context -
identifying the name of the waterbody off its coast. An area like the
Jamaica Bay example I gave earlier, with many islands and channels in a
tidal wetland, would also be extremely difficult to reason about in that

It is only once the spatial extent is determined that a renderer can do a
good job of label placement.  Of course, what the renderer does with that
information is highly dependent on the style of label to be used, but any
rendering that's at all more sophisticated than OSM/Carto's 'place a
single- or multi-line upright label on a point' needs the information.
You've given a very clever 'second best' approach to determining that
information when only a point is available - and I'm likely to find myself
using it because of the current state of the map data, so thank you for

Nevertheless, I think it would be much preferable to allow mappers to
communicate their intent. When mappers add a bay, inlet, gulf, fjörd, ...
to the map, they can be presumed to know what extent they would like the
object to have. What harm does it do if we give them a way to describe that
knowledge to others? Why the insistence on restricting the data model so
that we must use a brittle reconstruction technique rather than allowing
mappers to enter the extent of the object and data consumers to see it?

The two arguments that I hear so far appear to amount to:

- if any portion of an object's boundary is spatially indefinite, then that
object may not be represented as an area.

Farewell to several counties and townships in the northern part of my
state, then.

- carrying the data for bays is not scalable.

In that case, we need to open a much broader discussion of general
categories of data that we need to exclude from OSM in order to manage the
size of the data base or the complexity of the computations. I surely don't
want to start seeing conflicts between better- and worse-mapped regions
over perceived inequities in the allocation of server resources! If instead
of data volume, the concern is the complexity of processing large objects,
then it would perhaps be better addressed by a rule that "no area feature
should exceed more than X km², have a mapped boundary length of y km, or
require more than z nodes for its representation" - and then work out how
we want to handle exceptions like countries, large islands, and large lakes
and seas. (That's then the right time to discuss what to do about bays,
straits, estuaries, and similar features.) The argument would also have to
distinguish between the cost of maintaining the data on the server - the
real OSM - and the cost of processing the data in the OSM-Carto rendering
chain - OSM's public face. If there's a way to have the information in the
actual OSM 

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-15 Thread Kevin Kenny
On Thu, Nov 15, 2018 at 12:16 PM Christoph Hormann  wrote:

> > I'm afraid that I'm not following this argument very well. What about
> > a bay is 'completely non-verifiable?'
> The geometry.
> These geometries:
> are completely non-verifiable.  They add data but they does not add any
> substantial information about the verifiable geographic reality to the
> database that could not be represented with a single node.

We agree that those are mismapped examples.  If you're going to map a bay
as an area, extend its boundaries to the shore!

With these geometries:
> a large portion of the geometry and as a result the derived way_area are
> completely non-verifiable.  Also here a properly placed node would
> together with the coastline transport all the verifiable information
> about the geographic reality there is.

Even in that extreme example, having the spatial extent adds value.
Consider a large-scale map of the villages of Audierne and Poulgoazec, rendered on a
sheet of paper. How will the renderer of such a paper map determine that
the body of water on the southern edge of the sheet is to acquire the name,
'Baie D'Audierne', without information about the spatial extent of the bay?
(I do not ask this question in terms of any particular piece of rendering
software - and in particular not Mapnik-OSM Carto. The question is how,
even in theory, any conceivable renderer can be expected to make that

Does the same argument apply for an indentation in the coastline that's
more nearly totally enclosed?  Is the Sea of Azov mapped correctly? The Black
Sea?  Would the Adriatic Sea
deserve such treatment (right now it's just 'coastline' and maybe a node
that I can't find). The Ægean Sea? The Tyrrhenian Sea? The Ionian Sea? The
Gulf of Taranto? (Moving out to lesser and lesser amounts of enclosure.)

Closer to home for me, would Jamaica Bay (the area seen in rate a
multipolygon? RIght now it's just coastline, which leads it to be accounted
as 'Atlantic Ocean'. That would puzzle the locals, who often refer to 'the
ocean side' and 'the bay side' of the Rockaway Peninsula.  Here, too, the
extent of the bay is pretty well determined except for the precise location
of its mouth. (That one might most 'objectively' be placed at the narrowest
part of Rockaway Inlet, under the Marine Parkway Bridge, but local mariners
instead say that one enters Jamaica Bay when one crosses the imaginary line
between the lighthouse on the Rockaway Point jetty and the light on
Steeplechase Pier at Coney Island, and I generally defer to the locals when
it comes to knowing the extent of a place.) If I were to produce a
large-scale paper map of my former home town of Inwood, without spatial information,
how would my renderer know that the large water body at the left edge of
the sheet should be labeled, 'Jamaica Bay' or that the small one that would
likely appear on the sheet's southwest corner is Norton Basin? With partial
areas that are as represented as [multi]polygons, the rendering toolchain
that I use can handle the labels quite nicely today. I have absolutely no
idea how I'd make it go searching for a nearby node, or what to do when if
finds one.

Is the answer that, "if you want to produce such a map, OSM is the wrong
tool for the job'?  Or, 'well, given just the node, eventually a
sufficiently sophisticated AI will be able to reconstruct the area?'
Neither answer helps very much with the practical problem, although they
would at least inform me that I need to maintain hydrographic data separate
from OSM at least until such time as the miraculous AI arises.
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-15 Thread Kevin Kenny
On Thu, Nov 15, 2018 at 10:03 AM Frederik Ramm  wrote:

> > Long story short:  My suggestion is and has always been to map bays with
> > nodes in those cases where this - together with the coastline -
> > perfectly documents the verifiable information available on the
> > geometry of the bay.
> Agree on the node idea, but it would have to include some size signifier
> (and I think someone recently tried to add a "sqm" tag to water body
> nodes for that purpose which I also criticised...). I don't think you
> are recommending a relation that includes the actual coastline and the
> label node, but if you do then I am against that because I don't want
> every coastline to be part of 10 relations in the end.
Using point features alone defeats any attempt to do more sophisticated
label shaping than current Mapnik is capable of rendering.

Using coarse labeling polygons replaces the problem of having a shoreline
participate in multiple relations with the problem of having multiple
inaccurate representations of the same shoreline all running approximately
parallel. I can't see how that's any easier to manage. Moreover, it defeats
any sort of analysis that depends on adjacency. "The shoreline of the Gulf
of Bothnia" becomes a meaningless idea in that data model - it's just
another part of the coastline of Europe, with no reliable way of
identifying that Oulu is on that particular shoreline while Helsinki and
Tallinn are not. (I intentionally choose cases where ambiguity about the
mouth of the bay is not relevant.)

If the relation includes the actual boundaries (while having to be somewhat
arbitrary about indefinite ones), there's no need for a label node. Label
nodes that have the mapper identify where to put the label on an area
feature have no purpose other than label painting. They have no existence
in the field. They are purely tagging for the renderer.

Also, once again, could I ask you to make it clear whether you're
expressing your opinion or an official position of the DWG or the OSMF? The
fact that you deleted the relation - whcih, as you observe, some mapper put
some very careful work into - suggests that you are indeed expressing an
official position.  If it is an official position, I think the community is
owed a clearer statement of what the rules are - because the introductory
material on the Wiki appears very much to diverge from how the project is
actually being run. If I'm going to contribute to the map, I need some
reasonable likelihood that all my work won't be reverted because it offends
against rules that I do not comprehend. Reading the available documentation
has offered very little enlightenment.

I know that I've placed things in the map with which you personally
disagreed vehemently. In particular, I've performed a couple of imports
that you thought were entirely unwarranted - although by the end of the
discussion, the argument that was left standing was simply the
still-controversial one that imports always have a greater negative effect
on the community than the value of the imported data. After discussions on
talk-us and imports, you had the restraint not to revert the actual
imported data. Now you appear to be taking pride in what appears (without
researching the history) to be an arbitrary revert of a mapper's attempt to
curate the data manually, in a way that appears to comport with OSM's
multipolygon model but offends you because of opening the door to having a
way be a member of too many relations. In the absence of a more formal
guideline, I'm not really sure what to think, and wonder what among the
objects that I've mapped might be at risk.
Tagging mailing list

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-15 Thread Kevin Kenny
On Thu, Nov 15, 2018 at 6:11 AM Christoph Hormann  wrote:

> Mapping bays with polygons is always non-verifiable to a large extent.
> Mapping bays with polygons as you describe it above is always
> completely non-verifiable and amounts to pure (low quality) label
> painting which should not be done and should not be incentivized by
> maps with a mapper feedback goal.

I'm afraid that I'm not following this argument very well. What about a bay
is 'completely non-verifiable?'

The existence of the bay itself?  It's there. I can see it. The locals have
a name for it.

The fact that the bay comprises an area? Even common speech refers to
something being "in" or "out of" a bay - implying that the thing is an
area. "My ancestors earned their living gathering clams and oysters in
Jamaica Bay." "He sailed out from San Francisco Bay in search of
adventure." "Mariners entering the Bay of Fundy from the ocean must beware
of tidal rips." That sort of speech does not sound to me like the language
that describes a point. The thing is an area.

The fact that the boundary of the bay is in places indefinite?  Let's look
at the three sorts of ways surrounding the bay.

1. Coastline that the consensus of locals agree is the shoreline of the bay.
2. Coastline near the mouth of the bay, where there may be a certain degree
of 'fuzziness' about whether a particular square centimetre of water is or
is not part of the bay.
3. The entirely indefinite line across the water that encompasses the bay's
mouth and serves to close the polygon that defines the bay's shape.

I saee no problem at all with borrowing the ways that define the coastline
for (1.).  it's been drawn once, why draw it again?  If it's been drawn
imperfectly, that's an entirely different problem - unless you argue that
nothing should ever be mapped until its survey has reached whatever your
standard of perfection is. I really don't want to get into the situation
where we say to mappers, "you really can't map A until and unless you've
fixed B." That's a sure way to drive away a mapper who has valuable
information about A and doesn't care about B.

(2.) and (3.) are exactly the same problem that we see at the mouth of a
river, and here, as with rivers, the common understanding of the locals has
to come into play. I can recall an earlier thread in which I tried to apply
the 'objective' standard that someone proposed for river mouths to the
Hudson River in New York - and came up with the (to me) ludicrous
conclusion that the coastline, and the Atlantic Ocean, come up over 200  km
from New York City, and that the river has no independent existence until
that point and should not be named as a river on the map. Yes, it is
estuarine. It flows both ways, even in the long stretch where the water is
fresh. If your argument relates to the indefiniteness of the boundary, you
would be arguing that because a perfectly objective location for the river
mouth cannot be located, then the surface of the river cannot be an area.

I know from experience that some mappers advance that argument. I
personally find it ridiculous. Water features are subject to the same sort
of uncertainty as land features - the boundaries among seas, for instance,
are not well defined. But surely nobody would argue that a sailor embarking
in Venice or Trieste is sailing the Ionian Sea just because the boundaries
between it, the Ægean Sea, the Tyrrhenian Sea and the Adriatic Sea are all
indefinite. The Gulf of Bothnia and the Gulf of Finland both exist. Oulu is
one one and Tallinn is on the other, and they don't lose their existence as
areas just because there is no boundary on the water's surface.

If you argue, "well, rivers are different, you can model them with linear
features", I challenge you in the Hudson River example to come up with an
appropriate mapping for the Tappan Zee, a body of tidal water of
intermediate salinity, measuring about 5 km by 30, through which the Hudson

The same thing happens with land borders. Saint Lawrence and Franklin
Counties in New York are less than 100% defined because some kilometres of
their border are indefinite. The indefinite part is in an uninhabited tract
of swamp land that belongs to the state. Absolutely nobody cares where the
exact line is. All agree that surveying it could be delayed - in this case,
it has been delayed for a couple of centuries - until and unless there's
some dispute that gives a reason to fix it. But all the inhabitants of
those counties know what county they're in - because the border is
well-defined in the inhabited places where anyone cares about it. It used
to be that the boundaries between Saudi Arabia, Yemen, Oman and the
Emirates were similarly indefinite, simply because nobody cared about where
exactly an arbitrary line was in the middle of the great desert of ar-Rub'
al-Khali.  It's the same situation with the mouth of bays and rivers -
strike an arbitrary line, and improve it later if there is ever a reason.

You go on to 

Re: [Tagging] Estimated values for height

2018-11-13 Thread Kevin Kenny
On Tue, Nov 13, 2018 at 10:09 AM Sergio Manzi  wrote:

> Yeah, agreed. And I think in our context "*estimate*" should be more
> taken as "*quesstimate*", i.e. "*a first rough approximation pending a
> more accurate estimate, or it may be an educated guess at something for
> which no better information will become available*" [1].
> Now... how do we tag this... "*thing*"?  :-)
> My personal idea is that it should be:
> *either*
> *measure*:accuracy=estimate (e.g.: height=10 + "height:accuracy=estimate")
> *or*
> accuracy:*measure*=estimate (e.g.: height=10 + "accuracy:height=estimate")
> *and*
> get rid of all the est_* tags (e.g.: est_height=10)
 I'd mostly agree. When this gets wikified, let's make it clear, though,
that the ruleis "map what you know" rather than "don't map until you have
all the detail." (Too many discussions here come up with schemes where
mappers have to do additional research beyond what they can see in the
field before they can map in a conformant way. We don't want that.)

Now, as to the height of a tree. I've been tempted to map a few locally
spectacular examples, particularly of _Tsuga canadensis_ (and decided to
refrain: I had been thinking in terms of
just putting in the number of metres - but if I were to map such a thing,
ought I to distinguish:

- step back and simply visually estimate how many copies of my six-foot
hiking partner it would take to make the height of the tree.
- pace back a known distance (with the usual inaccuracy of pacing off a
distance) and use a clinometer to measure the angle subtended by the tree.
- frame the tree with stadia marks in a transit and tape off the distance
to the tree
- (I've never done this!) Climb the tree and drop a weighted tape.

The accuracy of these techniques varies by 4-5 orders of magnitude. The
simple visual method is probably going to have a standard error of a few
metres on a big tree (because I'm reasonably skilled at such things), which
can be reduced to tens of cm with the clinometer, a few cm with a transit
and tape, and sub-cm using direct measurement with a tape.  With the
specific example of a tree, nobody cares about a few cm, because trees
flex, and grow, and measurements aren't going to be repeatable to that
level (With a tower, it might become significant.)

At that point, for a tree, the only significant difference becomes "are
measurement errors of the same order of magnitude as the natural variation
in the measured quantity?" With a visual estimate, the answer is most
likely "no", with a clinometer and pace count, it becomes "yes," and
everything more sophisticated is mostly "wasted precision". So for a tree,
"measured" and "estimated" really are the only two categories that matter.
(And perhaps the date of the measurement. Trees grow, and the big ones all
eventually take storm damage and die back.)
Tagging mailing list

Re: [Tagging] رد: رد: New rag to draw node name with rotate angle

2018-11-10 Thread Kevin Kenny
On 11/10/18 8:52 AM, دار الآثار للنشر والتوزيع-صنعاء Dar Alathar-Yemen 

For OpenStreetMap rendrer:


*Somalia, Madagasikara,Yemen **اليمن, Oman **عمانwill be best if they 
have a rotate angle*

*India does not appear, Kynia has a chance to appear if Somalia has 
rotate angle also Ghana have chance to appear if down vertically*


*In MAPS.ME android*

*Seas: Red sea, Persian Gulf and many other seas will be view better 
with rotate angle*


*In All map renderers name of Sweden and Norway can be in middle if it 
have a rotate angle*


We all agree that rotated labels - or even better, curved labels - would 
improve the rendering.Most of us are arguing that having mappers tag 
place=* nodes with an angle is the wrong way to achieve this.

The renderer that I use for my personal experiments doesn't even use 
place=* nodes if there is a corresponding administrative boundary, 
because it has more flexibility in label placement if it ignores them.

I do intend at some point to experiment with implementing a Mapnik 
symbolizer that can do curved labels on area features - they'd be ideal 
for island chains (Japan, Hawai`i), chains of lakes, and mountain 
ranges, as well as for elongated countries like Chile or Norway, or 
elongated waterbodies such as the Adriatic Sea, the Gulf of Bothnia or 
Lake Nyasa.

If mappers were to specify rotation on place nodes, it would only get in 
the way of doing it right - for instance, the renderer would no longer 
be free to choose a different layout to avoid collisions.

It's awkward, too, for alternative renderers, such as navigation 
displays, that are not always north-at-the-top. I've done one (very 
simple) rendering at one point for a talk about a fire tower - it showed 
the plotting board of an Osborne alidade, with labels oriented to face 
the observer - labels at the near edge of the map would be upside down! 
A simple rotation of labels would not have been easy to compute, since 
the device also does not use anything resembling spherical Mercator, but 
rather a general perspective projection.

Tagging mailing list

Re: [Tagging] New rag to draw node name with rotate angle

2018-11-09 Thread Kevin Kenny
‪On Fri, Nov 9, 2018 at 12:06 PM ‫دار الآثار للنشر والتوزيع-صنعاء Dar
Alathar-Yemen‬‎  wrote:‬

> I suggest new tag to tell map render to draw the node name with a
> specified rotate angle not horizontal. We need this for some seas like Red
> Sea, and Suez Gulf in Egypt.

I have serious doubts whether encoding the rendering in the map in such a
way is a good idea.

A renderer that wished to label an area with an angled label could readily
determine the angle for itself, by computing the principal axes of the
area, and if its eccentricity exceeds a specified value, rotating the label
to align with the major axis.

An even better rendering could be achieved by computing the morphological
skeleton of the area, and placing the label along some smooth curve that
approximates the medial axis.

There are also algorithms that handle curved label placement in the
presence of interfering labels, although they are somewhat less well
developed. One such is described in Mathieu BARRAULT, "A methodology for
placement and evaluation of area map labels." _Computers, Environment and
Urban Systems_ 25 (2001), pp. 33-52.

Barrault describes the process of choosing a family of circular arcs that
well approximate the general contour of an area feature. Figure 3 of the
paper is informative about what criteria his heuristic takes into account
for 'goodness' of placement. Figures 10 and 11 show what the algorithm
achieves on sample elongated figures and Figures 13-14 show what it can do
in the presence of interfering labels.

To place this task on the mapper forecloses on the possibility that a
renderer can do it better.
Tagging mailing list

Re: [Tagging] How to tag named group of named water areas?

2018-11-08 Thread Kevin Kenny
On Thu, Nov 8, 2018 at 5:38 AM Dave Swarthout 

> Also agreed.
> I'm not saying anything about the route tag. We're talking about tags
> other than route or type, which actually set up the relation. The
> additional tags that describe the route or multipolygon either go on the
> relation or the ways depending on their scope, but not both.

Rather than 'depending on their scope', depending on the object to which
they belong.

Your choice of 'operator' as an example is a good one.  Here's one where,
if I had chosen to tag operators, I'd have three different operators, one
for an underlying way and one for each of two relations.

First, there's the way: .
That's where 'highway=secondary surface=asphalt etc.' goes: on the physical
way. The routers and renderers depend on this. Also, because of various
issues with data modeling, 'ref=*' sort of has to be there, but that's a
whole other discussion.  If I were to put an operator=* on the way, I'd put
Schoharie County Highway Department. That's who plows the snow, paints the
lines and fixes the potholes.

Next, there's the road route relation: . That's a road route.  It
gets "network", "ref", "symbol" and there's a Wikipedia entry for it.  If I
were to put an operator on it (I haven't) it would be "New York State
Department of Transportation." That's who established that numbered route,
and that's who allocates money for the county to maintain it, and that's
who establishes the standards for a third-class state reference route.

Finally, there's a piece of trail there. (I know for certain that
it's mismapped, the on-road section is shorter than what's on the map, but
I haven't been able to make time to get up there and fix it, and that's not
the point! By the way, the guidebook is also wrong.) The trail is simply on
the paved shoulder of the road at that point. If I'd tagged the operator of
that route, it would be the New York/New Jersey Trail Conference. That's
whom to get in touch with if there's a problem with visibility of waymarks,
or a higher-level problem with the routing. (Which there definitely is,
that's a dangerous place to have the trail, and the operator is trying to
fix it, but negotiations with the landowners proceed at a snail's pace.)

For convenience, that relation is in turn part of a larger route relation - this may be a mild abuse,
having a route as a member of a route, but the renderers such as Waymarked
Trails consume it happily.  This breakdown is done because the route is
highly fragmented, and having hundreds or thousands of ways in a single
route relation is pretty unmanageable. All of the member relations
duplicate the full tagging of the parent, so that if a data consumer cannot
handle hierarchical nesting of routes, everything will still work, and the
route will simply be 'Long Path (Schoharie County)' instead of 'Long Path'.

So -- a physical attribute (highway=*, surface=*, building=*, bridge=*,
whatever...) always goes on a physical object (a node, way, or
multipolygon). Relations other than multipolygons are not physical objects,
but conceptual groupings. They get the attributes that belong to the
groupings - name, operator, contact information, network, reference,
Wikipedia, website,  They do not get attributes of the physical objects
that compose them - those attributes belong to the objects and are not
generally understood to be inherited from the relation.

I think you you may have been confused because multipolygons are such a
powerful concept once you 'get it' - and physical tags on multipolygons are
Just Fine since multipolygons are physical objects. But multipolygons are a
special case among relations.  (The older scheme for tagging riverbanks is
another special case, but I consider it to be a legacy, and do not use it
for new mapping work.)

Specific types of relations may have further constraints. I can't speak to
public transport ones (since I don't map them). The only relations I use
are multipolygon, route (road, walking, hiking, horse, bicycle, ski,
snowmobile), boundary, and very occasionally a group (which I realize has
no recognized rendering but I don't know how else to tag the things). I do
waterways as multipolygons (one of several recognized ways to do them). I
don't do the networks for rail, power, or pipeline infrastructure - I map
the physical objects when I come across them in the field and consider them
significant landmarks, but don't try hard to tie them into the networks -
I'll leave that for someone else. I don't map complex traffic regulations
at all. For this reason, I can't speak to the specialized relations that
are used in these things, but I strongly suspect that they follow similar
rules of 'physical tags only on the physical objects and relations tagged
with only those attributes that conceptually 

Re: [Tagging] How to tag named group of named water areas?

2018-11-07 Thread Kevin Kenny

On 11/7/18 2:27 AM, Dave Swarthout wrote:
I provided two examples from the Wiki and a part of a response earlier 
in this thread from Kevin Kenny to support my argument that state that 
individual ways in a multipolygon or relation should not be tagged 
unless their characteristics require it.  If you're working with a 
route=road and the surface changes, you split the way and mark it so. 
Same with maxspeed or number of lanes. The characteristics are those 
of the way, not the entire route, and rightly belong only on the way.  
In the case of the pipeline, tags like man_made=pipeline, 
substance=oil, operator, Wikipedia and Wikidata tags, belong in the 
relation. The people who first added the pipeline to OSM did it both 
ways, probably to guarantee that it would be visible to OSM or other 
data consumers, but I don't know.

That isn''t quite what I said.

What I said is that attributes that conceptually *might* be different on 
separate ways of a relation belong on the ways. What goes on the 
relation are the things that define it as a relation.

For a multipolygon, that's everything. A multipolygon is nothing more 
nor less than an area feature with any topology more complex than a 
simple closed way. The way gets tagging only if there's stuff that 
really belongs to it; an example would be an administrative region that 
ends at the coastline.

For a route, what goes on the relation is specifically the name of the 
route (if it has one that might be separate from the names of the 
constituent ways - for example, the Erie Canalway briefly follows State 
Street), the network, the reference number, and any descriptive 
information such as operator, website, length, hours, ... The physical 
attributes (highway=*, surface=*, etc.) go on the component ways.

For a group, it's even less. The Great Lakes relation has pretty much 
just a name and the component relations for the individual lakes.

Sorry if my earlier explanation was confusing.

Tagging mailing list

Re: [Tagging] How to tag named group of named water areas?

2018-11-03 Thread Kevin Kenny
I probably should make a clarification about what I mean about "logically
belonging" to the relation.

On a road route, it wouldn't make sense to put 'lanes=2' or
'surface=concrete' on a road route, even if all the component ways happen
to have that characteristic. There's nothing to keep the highway department
from repaving one component way as 'surface=asphalt' or widening to
'lanes=4', and a mapper is likely to miss the fact that the relation is
claiming an attribute that properly belongs to the way.

On the other hand, network=*, ref=* operator=*, symbol=*, name=* and
similar attributes logically belong to the route itself, and won't change
as part of maintenance of the way. They go on the relation. For routes
(including route=pipeline, which is what we have here), tries to tabulate the
suggested keys that belong to the route itself.

On a multipolygon, as I observed before, every attribute belongs to the
multipolygon unless the way has some existence apart from its role in
defining the multipolygon boundary.
Tagging mailing list

Re: [Tagging] How to tag named group of named water areas?

2018-11-03 Thread Kevin Kenny
On Sat, Nov 3, 2018 at 9:45 AM Dave Swarthout 

> (*BOLD TEXT* is my addition) This is exactly what I've been saying*.
> Member ways should be untagged unless they have a separate meaning on their
> own. *
> There you have it. It's a logical system of tagging and makes perfect
> sense both from an initial standpoint and for ease of maintenance later on.

That's surely true of multipolygons.

At this point, except for the margins of [multi]polygons, the data model
doesn't really contemplate ways that need to be broken up because of size,
so to some extent you're breaking new ground here. In the road network,
what everyone does is just to split the way and repeat the tagging. Then,
anything like marked routes gets added atop the split ways, with only the
tags that pertain to the route.  Those tags don't get repeated on the way.
(An exception is ref=*, which doesn't work correctly in many renderers if
it is not on the way.) A better description might be that 'if a tag
conceptually would have an independent meaning on the member ways, it goes
on the member; if it logically pertains only to the collection, it goes on
the relation." For multipolygons, this is obvious - everything belongs on
the relation unless the way is being used independently, for instance, if
two administrative regions are divided by a road or stream.

This does add complexity if you're trying to analyze a long chain of ways
that shares a common characteristic.  It's a little tricky to follow
'Broadway' from the Battery in New York City to Sleepy Hollow in the Hudson
Valley, because everything changes about the ways (Even the name is not
100% consistent; there are variants like 'Old Broadway', 'New Broadway',
'South Broadway', and so on.)

Even the 'tag the collection attributes only on the relation' rule has a
couple of exceptions, but they're rare. They relate to the fact that
support for site and group relations, and routes-inside-routes ranges from
uncommon to nonexistent. Long and complex routes with many hundreds of
constituent ways are typically broken up into routes-inside-routes, so that
there are no more than a few dozen to a few hundred ways in each piece.
Examples include the New York Long Path and the Appalachian Trail (which seems to have picked
up a few problems; the top-level relation isn't supposed to have any ways,
only the subrelations). Because of the difficulties with
route-inside-route, group and site, it's easiest on these beasts to repeat
the tagging that appears on the top relation on each of the member
relations as well.  Waymarked Trails understands this sort of structure,
and can do both rendering and elevation profiling if the structure is done
right (For instance, the 'forward' direction in each of the subrelations
must match, and the subrelations must also run 'end to end': on both the
trails I list as examples, they run south to north).
Tagging mailing list

Re: [Tagging] Water collection points (in french "Borne de puisage")

2018-11-01 Thread Kevin Kenny
On Thu, Nov 1, 2018 at 10:25 AM Moritz  wrote:

> I would use
> man_made=standpipe
> colour=green
> water_source=main

If you use that tag, make sure that you wikify it and discuss
disambiguation, since 'standpipe' has many different meanings:

I don't mind the choice of word - because all words are ambiguous. We
simply have to document what *we* mean by it.

We should probably attach 'amenity=drinking_water' to standpipes that are
potable water sources.

'emergency=dry_standpipe' or 'emergency=fire_hydrant
fire_hydrant:type=wet_standpipe' could be used to document standpipes for
firefighting. (Dry standpipes would need both the inlets and outlets
marked; I'll leave it to someone else to work out the details, since I
don't have any I plan to map.)

Standpipe water towers (like the ones in Chicago, Louisville, or Mannheim)
are, of course, man_made=water_tower.

I don't foresee mapping standpipe piezometers, or standpipes on toilets,
washing machines or oil derricks.
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-30 Thread Kevin Kenny
On Tue, Oct 30, 2018 at 7:54 AM Dave Swarthout 

> Someone added the Arctic National Wildlife Refuge to OSM but did not add a
> bunch of inner areas that aren't part of the refuge. I have the inners in a
> shapefile that end up in a separate layer when I import them into JOSM. I
> would like to add those inners to the existing boundary of the refuge. How
> can I transfer those inners from the shape layer to my data layer?
> I've tried everything I can think of, including the special paste function
> inside the Relation Toolbox I learned about recently, but cannot get them
> to transfer *en masse*. I can copy and paste them one at a time but there
> are a few dozen tiny parcels. I also tried pasting them in place and then
> using JOSM's Search function to select "type:way untagged new" and that
> worked but it's clumsy.
> There must be a better way to do this.

If you have just the one multipolygon in the shapefile, or you have just
the inners in the shapefile, it's pretty easy.

Import the shapefile into JOSM. Yes, it comes in as a new layer.

Select the inner rings by whatever means.  One possibility is to delete the
outer ring (just don't save the shapefile again, or save it under a new
name before you start so that you can throw it away) and then 'Select All'
followed by 'Select->Unselect Nodes' (Shift+U). Copy the inner ways

Switch to the OSM layer and do Ctrl+Alt+V (Paste at Source Location).

You now have your newly pasted items selected. Bring up the relation editor
on your relation, and you'll see the selected items in the right-hand
column. Use the 'insert at the bottom' button in the middle bar to bring
them over. into the relation.

Now they're in the left-hand column, and still selected.  Type 'inner' in
the 'role' prompt at the bottom and hit the check mark. Now they're all
inner ways.

If you're afraid of losing the selection, add some tag like 'dave=1' to the
items before you copy-n-paste, and then the Search dialog can find them
easily. (Don't forget to delete the tag when you're done!)
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-29 Thread Kevin Kenny

On 10/29/18 2:48 AM, Dave Swarthout wrote:
But I'm still a bit confused about way:427547729. It's tagged as an 
outer in the Wilcox WF multipolygon but it's located inside of an 
enclosing way that's also an inner to the same relation. Does that 
mean the inner/outer roles alternate as you add more and more "nested" 
objects to the large multipolygon? For example,iIf there was a block 
of private property inside way:427547729 would that be tagged as inner?

You got it. That's why I chose that specific one as an example, to show 
how 'exclave within enclave' works. It's unusual, but it happens.

Just to touch on another topic because Kevin mentioned it. Sometimes 
it's fairly obvious that certain boundaries were meant to follow a 
riverbank or a coastline but at the present time don't. My first 
impulse is to delete segments of the original boundary and replace 
them with the more recent riverbank or coastline. That would probably 
be considered wrong by some but seeing as we do not and can not 
guarantee perfect accuracy with the placement of any boundary I don't 
see it as an absolute no-no. Plus, many of these boundaries use 
thousands of nodes that follow every little zig-zag to achieve legal 
accuracy. IMO, OSM doesn't need that level of detail.


I think you're right about the level of detail, and in fact I simplify 
ways fairly often.

Because partly of confusing advice here, in 'imports', in talk-us, and 
on the Wiki, when I did the reimport of the Adirondack protected areas, 
I did them as separate ways. In order to be able to simplify them, I 
used an 'erode' operation (a 'buffer' operation with negative size) 
where the size was slightly larger than the simplification tolerance to 
offset the ways before simplifying. At the time, I couldn't find such a 
beast in JOSM, so I used QGIS to do it.

What happened to change my mind was further discussion here about 
administrative boundaries, and the way that the offset ways looked 
around the corridors that were cut out of some areas for existing roads 
and railroads. I've been sporadically changing the borders from offset 
ways to shared ways. You can see a partly-done example at where the west 
side of Gooley Club Road is conflated and shared, while the east side is 
not. That's actually a 'not-too-bad' example since the Primitive Area 
corridor extends a hundred feet (~30 m) from the road centerline on 
either side. (Gotta fix the road designation, too - it's yet another 
TIGER Residential!. Grrr.) The corridor at applies 
'Primitive Area' protection to a three-rod right-of-way, and there was 
absolutely no way to get the ways simplified and aligned without 
conflating them (and in that case, why not make them a shared way?)

I still think my approach was valid for the initial import, particularly 
since the boundaries in the source data were drawn so as to require 
manual conflation otherwise. I discussed this issue at the time in 
'imports' and heard no complaints. In fact, one commenter thought that 
offsetting the ways automatically was fairly clever. For that reason, I 
haven't made the effort to go back and tidy everything. Still, if I 
happen to be maintaining an offset boundary for other reasons, I'll 
generally replace it with a shared way.

PS: This has been a most beneficial conversation. I feel enlightened.

That's gratifying. The more people who understand how multipolygons help 
with this sort of thing, the more we'll be able to dispel the idea that 
they're unworkable or unmaintainable.

Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-28 Thread Kevin Kenny
On Sun, Oct 28, 2018 at 8:12 PM Dave Swarthout 

> Okay, next question.
> I added the Laguna Atascosa National Wildlife Refuge to OSM yesterday . (I
> don't do much mapping in Texas but that place is special because I once did
> a water quality assessment there as a volunteer.) It's a fairly large
> multipolygon and the main relation holds the bulk of the refuge territory.
> However, there are scattered about several other areas, some of which are
> also multipolygons, that are part of the refuge.
> Simple areas can be easily included as "outers" in the main relation (Rel
> ID:885828). But what about other pieces that are multipolygons? I could
> simply add them as separate relations with identical tags but handling such
> areas that are connected administratively but not physically would seem to
> be one reason multipolygons were invented. But I'm thinking there must be a
> more elegant method. And what about inner areas that are also
> multipolygons? This case cannot be handled by my simplistic approach.

There's nothing wrong with having more than one segmented outer ring.

Have a look at relation 6362971 (use File->Download Object in JOSM) in the
relation editor, and you'll see just such an area, with muiltiple segmented
outer rings, and some of the segmentation is there to have shared ways.  If
you also download 6370357, you'll see how the two relations share some, but
not all, of the ways. Relation 8428216 might also interest you. It's a case
where the same protected area shares multiple, noncontiguous segments with
a lake shore, and multiple, also noncontiguous, segments with an adjacent
protected area.

Way 427547737 is also interesting. It's tagged place=islet (because it
is).  It's an inner way of Lens Lake, and an outer way of Wilcox Lake Wild
Forest. Since the lake is not part of the Wild Forest, but is part of a
private inholding that is completely surrounded by the Wild Forest, its
west shore is an outer way of the lake and an inner way of the Wild
Forest.  And the inner ring to which that way belongs completely surrounds
the islet.

(The shoreline looks wrong in places, but I'm not going to fix it, because
it's way too hard to tell land from water in orthos of beaver swamp.

Because research is needed to find out whether, for instance, a nature
reserve boundary that appears to run along a shoreline actually follows the
shoreline or rather follows some survey line that was the shoreline in
times past, I generally do this sort of conflation only when resolving
conflicts or reimporting a particular boundary, so you'll see a lot of
imported borders up in the Adirondacks that don't use shared ways yet. You
can still use them as examples of how arbitrarily complex the topology can
get.  That Wilcox Lake Wild Forest relation (6360587) to which that islet
belongs is pretty crazy, because it's a ton of small parcels.
Tagging mailing list

Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread Kevin Kenny
On Fri, Oct 26, 2018, 20:05 Warin <> wrote:

> On 27/10/18 02:41, SelfishSeahorse wrote:
> > On Fri, 26 Oct 2018 at 08:23, Martin Koppenhoefer
> >  wrote:
> >> On the other hand, speaking about “numbers”, those are probably facts
> and not protectable by copyright
> > If i'm not mistaken, numbers aren't protected by copyright, but a
> > compilation of numbers (i.e. a database) can be protected; if not by
> > copyright then by so-called database right. See:
> >
> >
> >
> US law does not apply everywhere.

Obviously, since those articles are about a sui generis database right that
US law does not recognize.

Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-26 Thread Kevin Kenny
> 26. Oct 2018 11:52 by
> Thanks, That helps a lot. I don't work with routes (yet) but it when I'm
> adding inners to riverbank multipolygons I always add them in the order
> they would appear if you were traveling downstream. It just makes sense to
> me although there's probably no programmatic reason to do it.
> On Fri, Oct 26, 2018 at 5:55 AM Mateusz Konieczny 
> Order of elements is saved in OSM database.

That appears to be the answer to a different question.

The 'sort' operation in the JOSM relation editor changes the order of the
elements. If the layer is uploaded, the new order of elements, as produced
by the 'sort' operation, will replace the old order in the OSM database.

This is usually what I want with a multipolygon. With a route, I find
myself undoing or further altering a 'sort' operation much more often,
because there are often things about routes that JOSM doesn't get quite
right. (Example - a dual carriageway where both ways end in link elements
looks as if the route has floating endpoints, and the sort operation messes
up one of the directions.) Even there, though, the 'sort' is usually Pretty
Close to right, and is often usable as a starting point. Moreover, I'm not
sure that it can be improved. The topology of a route isn't always quite
right in the field, and some of 'getting it better' amount to 'read the
mapper's mind,' something computers are ordinarily not well equipped to do.
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-25 Thread Kevin Kenny
On Thu, Oct 25, 2018 at 10:40 PM Dave Swarthout 

> Thanks again, Adam.
> That was also helpful. It brings up a question about sorting. After
> sorting, are the elements arranged according to their coordinates, that is
> to say, spatially? Or nearest node at each end of a member way is checked
> to see which other node ways are closest? Or what?

It's a little complicated.  The gist is that 'sort' tries to hook as much
together as possible so that the ways are in 'the right order'.

It starts by making the longest chains possible by putting the ways with
common endpoints together.

Once that's done, I *think* that it greedlly starts with the longest open
chain and drops that in place. Then it successively finds the nearest
endpoint on another open chain and starts from there, so that the gaps are
as short as possible. This may not be the best choice, particularly if the
relation is really messed up, but at least it connects what it can, and if
you zoom to the disconnected ways, you can eyeball where you want them to

Routes are slightly more complicated, but once you learn to read the column
with the arrows in the relation editor, you'll pretty quickly be able to
figure out what's going on.  in that column, the arrows join if the ways
share an endpoint, and the arrowhead points in the direction of the way. If
the ways form a closed ring, the arrows will, too. In a multipolygon, if
all the ways don't form closed rings after sorting, there's a problem.
Tagging mailing list

Re: [Tagging] Radio telescopes

2018-10-25 Thread Kevin Kenny
On Thu, Oct 25, 2018 at 4:46 PM Warin <> wrote:

> On 25/10/18 23:56, Paul Allen wrote:
> BTW, these days few radio telescopes are dishes.  Most of them are phased
> arrays and not on towers
> or masts.
> That depends on the frequency of operation.
> New dish reflecting ones are being build. They simply perform the best for
> the intended frequencies.

And there are dishes with phased arrays at the feed point, for beam
forming, and phased arrays of dishes, for long-baseline interferometry.  It
all depends on what frequency, SNR, polarization and angular resolution you
need. Paul is right that larger phased arrays are now practicable because
of better electronics, giving dishes less of an advantage, but phased
arrays are as old as radio astronomy. Jansky built his "merry-go-round"
Bruce antenna (20.5 MHz) in 1932, while Reber didn't build his first dish
until 1937. Jocelyn Bell discovered pulsars on a phased array built at
Cambridge by Ryle and Hewish (which also produced the 3C catalog of radio
sources - including 3C273, the first known quasar).

The conclusion is either, "Life is full of tradeoffs," or "you really don't
want to know!"
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-24 Thread Kevin Kenny
> On Wed, Oct 24, 2018 at 4:19 PM Allan Mustard  wrote:
>> Please do continue to comment and to offer suggestions, and to pose
>> questions.
>  This is pretty much based on gut feelings and may be partially or
> completely wrong...
> I don't think "amenity" is a suitable tag for a consulate.  Amenities are
> parks, or toilets, or similar.
> "Should we go to the park or the consulate for a picnic today?"   "I'm
> busting for a crap, where's the
> nearest consulate?"  And I'm damned sure an embassy isn't an amenity (I'm
> not even sure, in these
> days of telecommunications, if it serves any purpose other than housing
> spies, but if heads of state
> do still use embassies for formal communication between governments
> they're definitely not
> amenities).
> I'm not going to worry too much about that particular tagging.
'amenity=*' is so overloaded in OSM (amenity=prison? Really?) that it can't
possibly get any worse. Since I already have to account for a great many
different sorts of cases when processing 'amenity=*' for rendering or
analysis, one more would be lost in the noise. I tend to think of OSM's
'amenity' as having a meaning not too far removed from 'thing'.
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-23 Thread Kevin Kenny
The Holy See is sovereign, so its nunciatures are embassies by another name.

On Tue, Oct 23, 2018 at 8:20 PM Warin <> wrote:

> Umm .. here is some sort of exception.
> "Apostolic Nunciature of The Holy See" ... :-)
> Ok .. what is it (in OSM terms)? Presently in the data base as
> amenity=embassy
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-23 Thread Kevin Kenny
On Mon, Oct 22, 2018 at 12:36 PM Adam Franco  wrote:

> Hi Dave, all,
> Based on this discussion I just recorded this short tutorial
>  of how I use JOSM and its Relation Toolbox
> plugin to to add adjoining land-cover areas as multipolygons with shared
> boundary ways to reduce duplication and overlapping ways.

Thanks for recording that! Now I don't have to. :)

Your workflow is essentially the same as mine, except that I use the
regular old relation editor to add and delete ways. Works well enough for
me, and I think it's only one or two clicks more than what you're doing. I
also make a lot of use of 'replace geometry' from utlilsplugin2, since a
lot of what I'm editing was born as imports and is being replaced with
updated data from the same sources. Yes, I'm very careful not to step on
the work of local mappers when I do it.

Depending on what's going on in the field, I might have called that
hedgerow a tree_row or a hedge and used a linear feature to map it.
Similarly, at breaks in tree cover for things like power lines and
pipelines, I might use man_made=cutline. Speeds up the process a little bit
more. For what it's worth, I tend to restrict the 'cutline' tag to a
standard (in NY) four-rod right-of-way; if the cutting is larger than that,
it gets a polygon.

Hopefully this will begin to show that for complex landcover, or similarly
complex admin boundaries, that multipolygons with shared ways are actually
quicker and easier to maintain than simple areas.  I know that they're
still controversial, even among experienced mappers, but for something
complicated like West Point,
with a whole bunch of shared borders, rights-of-way cut out of it and what
not, I'd be really handicapped without shared ways.  I didn't get very far
on the landcover because I seldom map landcover other than in my own
neighbourhood or when fixing other people's mistakes.
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-21 Thread Kevin Kenny
On Sun, Oct 21, 2018 at 7:19 PM Warin <> wrote:

> I used the OSM diary entry to do Public Transport. Might work for you .
> People can make comments under it .. and you can edit the first entry you
> made to correct errors and make changes.
> See
> Videos are like lessons... you need to be very well prepared to present
> them. Written stuff you can do fairly easily and review later. A
> presentation (video/lesson) should be correct the first time around. For
> preference .. I'd write it .. much less stress.

Well, of course. I've spent enough hours standing in front of a classroom
to understand that. For me, a video script is a lot harder to write and
present than a lesson plan or a conference talk. In front of a classroom, I
can see whether the students are getting it, and change the pacing
accordingly. I can't do that with a camera.
Tagging mailing list

Re: [Tagging] Power=cable for low voltage lines?

2018-10-21 Thread Kevin Kenny
On Sun, Oct 21, 2018 at 2:49 PM Paul Allen  wrote:

> We shouldn't be asking mappers to guess if it's a line, a minor_line or a
> cable before they can map anything.  Those distinctions are
> refinements that can be added later if further information becomes
> available.

Thank you for continuing to point this out.

I'm a hiker, and a large part of my OSM work is to support that activity.

When I map a power line, it's because I encounter one running through the
back country, and those things are important landmarks for hikers. I record
a power line in my field notes. even if I haven't followed it. When I get
home, I may well map what I can see of it on orthoimages. I think that many
of these are subtransmission lines, likely 69 kV, with the occasional 115
kV line thrown in for good measure. But I'm not sure - and I shouldn't have
to research what the voltage is, whether the conductors are insulated or
not, or what the power grid topology is, before I can map that "there are
overhead conductors, and (wooden/steel) (poles/H-frames/towers) visible in
the field here." If I have to do any kind of research before I can begin to
map an object that I can see with my own eyeballs in the field, something's
wrong with the model.
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-21 Thread Kevin Kenny
On Sun, Oct 21, 2018 at 7:34 AM bkil  wrote:

> It seems many would find a short video tutorial depicting these steps very
> handy. Would you mind sharing on Bitchute or on some other video hosting
> site?

On Sun, Oct 21, 2018 at 9:00 AM Dave Swarthout 

> I was wishing that someone would write a short tutorial about relations,
> the various concepts about tagging them, and problem solving when something
> goes wrong with one. I have been unable to understand with any degree of
> certainty how and why we create them, which is the reason I started this
> thread and contributed to the other one about tagging groups of lakes. The
> Wiki is helpful but leaves out a lot of details. A tutorial, video or
> otherwise, would be extremely helpful.

On Sun, Oct 21, 2018 at 1:24 PM Mateusz Konieczny 

> Maybe improving wiki would be a good idea as the first [step].

I find that video tutorials don't often fit my learning style, so I don't
often use them and have never made one. Moreover, I'm an old man and
somewhat set in my ways. Nevertheless, they seem to be demanded, and if
nobody else steps forward, perhaps it will be possible to teach this old
dog that new trick.  I'd be willing to take a whack at a written tutorial,
but can't promise any particular time frame. Just at the moment, I'm
chronically busy.

The right place might be the Wiki, but I've two reservations. First, I've
simply burnt my fingers too many times when touching a Wikipedia page.
Perhaps this community is a trifle less fiery? Second, what I've seen on
OSM's Wiki (as well as Wikipedia and others) is that editors jump in to add
details that make the presentation more "correct," but less approachable to
a newcomer. For an introductory tutorial, this drift is disastrous, because
introductory material frequently is in the form of a "lie to children" that is not techinically
accurate, but provides enough of a mental model to do simple things and
prepares the mind to accept a more complete explanation later.

One thing that I will surely not be able to accomplish is to ferret out all
the obsolete and misleading information about relations that there is on
the Wiki. The community has had a complex history of groping toward a
theory of relations as it stands today, with several false paths along the
way. For example, I'm pretty sure that there are still Wiki pages out there
advising to place the tags that belong to a multipolygon on the (presumed
unique) outer ring. Moreover, there is bound to be similar groping in the
future as we grapple with representing ever more complex things, e.g.,
"traffic must stop at this intersection, except for right-turning traffic
in the rightmost lane, which need only give way to conflicting traffic," or
"this parking field is exclusively for the use of these three stores, all
of which are some distance down the street, not contiguous with it."

Nevertheless, there are particular relations that are surrounded by
considerably less remaining controversy and supported by extensive usage.
Among these are multipolygons, administrative boundaries (really a special
case of multipolygons, but we got there by a different path), waterways
(again, a special case of multipolygons, and this time, multipolygons
provide an acceptable alternative), and routes (bus, road, hiking, cycling,
etc.)  A tutorial or series of tutorials could certainly cover these
relations and leave the fine details, about which we quite rightly love to
argue, to a more advanced student.

I'm certainly unable to create such a help page or tutorial but someone
> with more experience should. I use relations often but when one develops an
> error, I'm usually hard pressed to fix it. As OSM becomes ever more
> sophisticated the learning curve gets steeper and mappers, especially
> beginners, will make tons of errors when using relations and won't have any
> idea how to go about fixing them.

 If I were to take on this task (again, no guarantees about the time
frame), I could certainly address this issue with JOSM (and possibly
Meerkartor). I surely do not know Potlatch2, iD, or any other tool well
enough to manage anything but the simplest of relations in it, nor do I see
obvious things in the UI that would do what I need. It may well be
limitations of the tools, rather than limitations of knowledge and
training, that make people assert that relations are unmaintainable or that
drawing complex boundaries twice is easier than creating multipolygons with
shared ways. That last statement, however, may be nothing but a base libel
based on ignorance. In that case, I'm more than willing to be enlighened.
It would occasionally be handy to be able to make a quick change to a
multipolygon when I'm away from a machine that has my preferred tools and
simply working in a browser.
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-21 Thread Kevin Kenny
On Sun, Oct 21, 2018 at 6:46 PM Warin <> wrote:

> Err .. in some places .. 'leaves down' does not occur :)

Yes. However, the fact that "leaves down" images are needed in *those*
particular places to distinguish forest from water strongly suggests that
there isn't another area in between the two.
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-21 Thread Kevin Kenny
I'm somewhat familiar with a couple of places that Alaska Dave has mapped,
and they're the sort of places where the shoreline must be mapped from
winter, 'leaves down' aerials, because otherwise the shoreline is obscured
by overhanging trees and matted aquatic vegetation.

On Sun, Oct 21, 2018, 13:42 Mateusz Konieczny 

> Is forest starting immediately on the water edge or is there a
> beach/marsh/whatever between
> water and forest?
> With shoreline as border of both water and forest it is OK to reuse it, if
> there is - even
> currently unmapped - feature between them then reusing ways is only going
> to make
> life of future mappers more irritating.
> 20. Oct 2018 11:38 by
> Another situation that occurs quite frequently in my mapping (in Alaska
> especially), is when an island defined by natural=coastline is also covered
> right to the water with natural=wood. Usually, I duplicate the coastline,
> shrink it a bit, and then tag it with natural=wood. But yesterday I tried
> something new, new for me anyway, and that was to create a single-member
> multipolygon from the coastline way and then tag the resultant relation
> with natural=wood in order to reduce the number of nodes used. I was
> pleased that JOSM didn't complain and that the island seemed to render okay
> but I'm not sure this is a legitimate procedure.
> ,
> The island is at 58.56588, -152.59579 and the relation ID=8828482
> What do you think is the best approach to handle this situation?
> Dave
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-20 Thread Kevin Kenny
> Works great, right up until you need to maintain it.  So, you've got
> your "natural=wood" multipolygon sharing a way with an adjoining
> "natural=scrub".  And then, some inconsiderate developer bulldozes his
> way across the boundary and puts up a housing development.  Now what do
> you do?  You can't unglue the boundary and shrink the two affected
> areas to make room for the "landuse=residential" because there's only
> one way.
> The only option I've found is to remove the affected section of
> boundary from one of the multipolygons, move it to the new location,
> create a new boundary way for the other multipolygon in the proper
> place and add it, create a new multipolygon for the development and add
> the relevant boundary ways to it, and then confirm that you haven't
> broken any of the multipolygons involved.  It's painful enough that
> it's usually faster and easier just to delete everything and re-create
> them from scratch as ordinary closed ways.

I actually do edit those things pretty routinely. It involves redrawing
only for the added ways.

Draw the new closed polygon representing the landuse=residential. Make it a
multipolygon immediately.

Insert nodes at the intersections of this closed way with the existing ways
(if you didn't draw it that way to start with). Split the old and new ways
on the nodes. (Splitting is safe - they're multipolygons already.) JOSM has
an 'add nodes at intersections' feature that helps with this.

Edit each of the old multipolygons to replace their old boundaries with the
new ones. That's just 'remove the old ways, insert the new ones' in the
relation editor.

Finally, delete any ways that are now unused.

I can do this *lots* faster than I can redraw an irregular boundary, at
least in JOSM. (I'm not skilled enough with iD to comment. it wasn't much
harder in Meerkartor when I tried it.)

Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-20 Thread Kevin Kenny
It conflicts with natural=coastline

On Sat, Oct 20, 2018, 10:36 marc marc  wrote:

> > create a single-member multipolygon from the coastline way
> > and then tag the resultant relation with natural=wood
> I often put the natural=wood on the inner way itself
> it's not working for some apps/render style ?
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Another multipolygon question

2018-10-20 Thread Kevin Kenny
Not only legitimate,  but recommended!

If you haven't stumbled on it yet, another useful procedure is to map areas
of landuse use or landcover by drawing each border only once, and having
each area be a multipolygon with the shared border way as a member. With
that approach there's no need to retrace an irregular boundary. You just
add it to the multipolygon on either side.

For an example, look at West Point. and how the shared ways with
the parks, cemeteries, golf courses, and so on are handled. It means that
even simple areas like
become multipolygons, but it ensures that the boundaries all stay
consistent, because you need to map each one only once.

On Sat, Oct 20, 2018, 06:22 Martin Koppenhoefer 

> sent from a phone
> > On 20. Oct 2018, at 11:38, Dave Swarthout 
> wrote:
> >
> > But yesterday I tried something new, new for me anyway, and that was to
> create a single-member multipolygon from the coastline way and then tag the
> resultant relation with natural=wood in order to reduce the number of nodes
> used. I was pleased that JOSM didn't complain and that the island seemed to
> render okay but I'm not sure this is a legitimate procedure
> I also do this, for example if there’s a fence but I also want to tag the
> area it delimits. Or for buildings and things that are there, in some cases.
> Cheers, Martin
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] How to tag named group of named water areas?

2018-10-12 Thread Kevin Kenny
> why not a multipolygon? I agree that you don’t need additional tags for a
> group relation, just type=group, a name and the members, but for a site you
> would need something that describes the site, a tag for a group of water
> areas, so as long as all the members are areas (or parts), a multipolygon
> would be better.

When the lakes themselves are complex multipolygons with many islands,
repeating that data for the group is likely to be a maintenance nightmare.
(I know this from curating boundary=protected_area relations that include
partial shorelines on such lakes. It's especially fun when the boundary
splits islands.)

Tagging mailing list

Re: [Tagging] How to tag named group of named water areas?

2018-10-08 Thread Kevin Kenny
Group relations have been proposed ( in
the past. One has been used to group the Great Lakes:

I'm tempted to use type=group relations to group the Bisby Lakes,, the Cedar Lakes (First,
Second, Third and Fourth are all conflated in OSM), the Essex Chain of Lakes, the Fulton Chain of Lakes:, and similar groupings,
because the unimaginative names of the individual lakes are, to say the
least, uninformative. If enough people use type=group, the renderers,
Nominatim, and other data consumers will eventually catch up, I suppose.

Note that US Geologic Survey topo maps have historically indicated the
chain names as well as the lake names, so the USGS cartographers have
considered both names to be significant:,-74.23618=14=t=r=0.25
shows the Essex Chain and,-74.90313=14=t=r=0.25 shows
the foot of the Fulton Chain, for instance.

I haven't tried to push this issue, because the rendering world is truly
not ready for it.  One of these years I'm going to want to try my hand at
implementing a renderer that incorporates some of the ideas of and
for labeling elongated areas and groups (such as archipelagoes, mountain
ranges, broad rivers, and chains of lakes). Don't expect it any time soon.
So many projects, so little time...

On Mon, Oct 8, 2018 at 10:24 AM SelfishSeahorse 

> On Mon, 8 Oct 2018 at 13:55, SelfishSeahorse 
> wrote:
> >
> > On Mon, 8 Oct 2018 at 13:13, Martin Koppenhoefer 
> wrote:
> > >
> > > A very similar problem are parts of lakes by the way, e.g. look at
> this map of the lake of Constance, showing names for parts of the lake:
> > > (or maybe the "lake" in this case is a group of lakes as well).
> >
> > This problem could be solved with *:part=* areas (in this example
> > natural:part=lake), analogous to building:part=*.
> PS: Sorry, i meant natural:part=water (+ water=lake).
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] hydrants

2018-10-08 Thread Kevin Kenny
On Sun, Oct 7, 2018 at 6:14 PM Rich  wrote:
> > Instead of
> > fire_hydrant:opening=cw
> > fire_hydrant:opening=ccw
> >
> > You need to type:
> > fire_hydrant:opening:direction=clockwise
> > fire_hydrant:opening:direction=anticlockwise
> >
> > Also, because the primary usage for `direction` usually relates to
> > heading, you could interpret the tag as an answer to the question "in
> > what direction does the opening of the fire hydrant face"?
> What about using the standard engineering terms:
> fire_hydrant:handedness=right
> fire_hydrant:handedness=left

With a typical hydrant valve, a right-hand screw thread becomes 'turn left
to open' and vice versa.

One hopes that the caps and the valve(s) both open in the same direction,
but there are lots of strange old hydrants about. Most of the ones near me
have markings like




on both the caps and the bonnet.
Tagging mailing list

Re: [Tagging] Map a divide?

2018-10-04 Thread Kevin Kenny
On Thu, Oct 4, 2018 at 6:26 PM Warin <> wrote:
> A land form ridge too me is a long, narrow raised part of a high edge formed 
> by hill/mountains and there associated bits.
> A land form of a dividing range or continental divide does not have to be 
> narrow,
> The 'dividing line' marks the separate water flow from one side to the other 
> and should be 'long'.

That divide is, ipso facto, a ridge line, because water flows downhill
- it is a line that's higher than the basins on either side. It runs
from peak to saddle to peak to saddle (admittedly, the 'peaks' may be
of but little prominence) for the length of the divide.

In any case, the place where I mean to map the divide is terrain of
considerable complexity, topographically. Its high point is the most
topographically prominent feature between Vermont and West Virginia.
The divide unquestionably runs for the most part along high ridges.
The 'ridge' nature gets lost only at a handful of saddles that are in
relatively high-elevation wetlands - but those flat lands are still
some hundreds of metres above the valley floors of the two rivers
whose basins it divides. The complexity comes from the fact that the
place is not a mountain range geologically. It is a 'dissected
plateau', whose 'peaks' are actually arêtes between chasms excavated
by glacial action. The direction of glacial flow was not consistent
among the glacial epochs, so the ridges tend to run higgledy-piggledy,
and one reason for mapping the divide is that it is otherwise tricky
to follow visually. It wanders quite a lot.

I live among some of the oldest exposed rock on the planet -
surrounding me are sediments from the early Palæozoic, and to the
north is the Canadian Shield, with its oldest rock dating to the
Hadean Æon, with its oldest samples having an estimated formation of
4.2 × 10⁹ years ago. Consequently, the mountains here are all rounded
and eroded. The ridges, except for the cols at the boundaries of
glacial cirques, are therefore broader and flatter-topped than you
appear to imagine - but they still rise distinctly above the
surrounding valleys.

Can we agree that,, and are all indeed views
of a ridge? (In the last photo, ignore the mountains on the horizon,
they're in a different range - the ridge runs diagonally away from the
right foreground).

Or check out the contour lines (elevations in feet; my users are
American) along the Devil's Path
and tell me that I'm not dealing with a ridge!

Open question - which I'll resolve for myself - is how much
topographic prominence to use when labeling peaks and saddles.  I
think I'll probably follow the local hiking clubs, and say, '150 feet
(about 45 m) of prominence, and 1 km separation' for mapping peaks and
their key cols, and at this point I care about the key cols mostly so
as to keep the topology of the divide continuous - although I'll
surely map the names of the saddles where I know them! (They do have
local names, even though they aren't listed in GNIS or appear on very
many maps. But the locals could tell you where to find Mink Hollow,
Stony Clove, Lockwood Gap, Winisook Pass or Pecoy Notch - and yes, we
use all those words in toponyms, reflecting the Babel of languages
that our settlers spoke.)

Tagging mailing list

[Tagging] Map a divide?

2018-10-04 Thread Kevin Kenny
In some maps that I render, I want to show the divide between a couple
of major river basins. (I have a good DEM for the area in question and
can derive the line readily.)

In light of the recent thread on topographic prominence, I wonder if
this is sufficiently interesting information at least to push it to
OSM. (If not, that's fine, I have a PostGIS database and a bucket of
shapefiles and know what to do.)

If it is sufficiently interesting, the question then arises: how to map/tag it?

'natural=ridge' comes to mind, and the divide in question has a local
name. (The 'Catskill Divide' separates the basins of the Hudson and
Delaware Rivers.) This approach appears to run into problems, as I
read the Wiki. I see:

> The way should connect saddle points and peaks, and the arrows should point 
> upwards.

That may be all right for a ridge ascending the flank of a single
mountain, but what I'm talking about is the spine of a range, with the
ridge traversing dozens of named peaks. Even with a single mountain,
if there are false summits, the arrows on a single way cannot point
upward all the time! (And the wiki is clear that the

Do I misread, and should the reading instead simply be that the
arrowhead should be higher than the arrow tail? In that case, I could
break the divide into two ways, with a common endpoint at the highest
summit in the range.

Consider this a low-priority item. I have (or will have - there is a
bit of debugging yet) the data. I know how to render them. I'm happy
enough with a shapefile or a private PostGIS table if others aren't

Tagging mailing list

Re: [Tagging] My "weirdly unnatural aversion to relations"

2018-10-02 Thread Kevin Kenny
On Tue, Oct 2, 2018 at 12:03 PM Paul Allen  wrote:
> Even if a multipolygon can have many disconnected outers, it seems I'd have 
> to make each university
> building an outer.  And then there are no inners.  So even if it can be done 
> that way, it seems like
> an abuse of the concept, which I thought was to be able to punch exclusionary 
> holes in areas.

The one that I pointed you at has a great many disconnected outers.
It's called a MULTIpolygon precisely because it can represent multiple

Most GIS software calls your idea of a multipolygon simply a
'polygon', and the OSM concept of a 'closed way' is a 'ring'.  Hence,
in ordinary GIS terminology, a 'ring' must be a simple closed region,
a 'polygon' has an outer ring and zero or more inner rings, and a
'multipolygon' may have multiple outer rings.

If mapping a complex area like as a multipolygon with
disconnected outer rings is an 'abuse of the concept', that's news to
me - and I'd really like to know what the accepted concept for how to
map those is, because I've mapped hundreds of cases like it (well. all
right, it's an outlier at the high end of complexity, but I'm sure
that I've got hundreds of multipolygons with disconnected components).

I don't see adding the lot of an isolated building to a multipolygon
as being any more difficult than adding it to a site.

If the university's holding is an office or floor, represented by a
node in OSM, in addition to land area elsewhere, that might be a call
for a different type of relation, since only ways make sense as
components of a multipolygon. If 'site' is the correct description of
that, so be it.  I haven't yet confronted mapping that particular sort
of beast, but I concede that I can see wanting to map, "the university
comprises this lot of buildings and grounds, as well as operating out
of these offices and storefronts' - and a multipoygon can't do that.

Still, in any case, when a particular region or facility comprises
disconnected parcels of land, a multipolygon with disjoint outer rings
is a natural way to map it, and all the tools cope with that topology
quite well indeed.

Tagging mailing list

Re: [Tagging] My "weirdly unnatural aversion to relations"

2018-10-02 Thread Kevin Kenny
On Tue, Oct 2, 2018 at 11:15 AM Paul Allen  wrote:
>> Why selecting buildings and tagging them to site relation is easier than 
>> selecting building and adding them to  a multipolygon realation?
> I can't even begin to comprehend how that would possibly work.
> Well, maybe I can.  If we make the outer role of the polygon "not university" 
> then we can add the
> individual, scattered buildings as inner role "university."  Seems bizarre to 
> me, but feasible.  It's
> analogous to the way you can use a multipolygon to define a wood with ponds 
> in it.  Except
> "wood" is a concrete term everyone understands but "not university" is not.
> If we make the outer role "university" then the inner roles have to be all 
> the places that the
> university buildings are not, with role "not university."  Not only do we 
> have the conceptual
> problem of "not university" but it would be very fiddly to map.
> I can't see any way of using multipolygons for this case that makes sense and 
> is easy to do.  If
> you can, then please explain it.
> A site relation, however, is simple.  Just add each building to the relation. 
>  Why do you consider
> this to be no easier than the multipolygon approach?

Are you labouring under the misapprehension that a multipolygon has to
have a single outer ring? Otherwise, what you're saying makes no sense
at all to me.

I routinely map state lands that have quite complicated topology, with
holes, islands, disconnected parcels, cutout rights-of-way, just about
everything you can imagine. is an example of how
irregular things can get.  That's a single multipolygon, and that's
the approach that I'd use for the sprawling campus that you describe.

I'm willing to be convinced that site relations are useful, but your
example doesn't convince me.

I agree that relations are underused, but I also agree that PART of
the reason is that only a few types of relation so far (multipolygon,
route, possibly group) are sufficiently well structured that the tools
have something to go on.

Tagging mailing list

Re: [Tagging] Traffic sign direction tagging..

2018-10-01 Thread Kevin Kenny
On Mon, Oct 1, 2018 at 4:31 AM Paul Norman  wrote:
> Could you provide a link to the osm2pgql issue tracker with the issue in 
> question? I don't recall it, but I've been away a lot and haven't kept up 
> with everything.

I hadn't opened a fresh ticket, because there are existing tickets
against the tools, notably

I also made a query to the 'tile-serving' mailing list.

The proposal can be found here:

and I'm asking that comments be posted against this issue:

Where I've got so far is that I have a stand-alone converter that can
produce the
tables by querying the slim tables (Yes, I understand why that's a bad idea, but
it's what I have to work with before I start bashing away at osm2pgsql, and it
at least gets me rendering. It's also a very fast way to upgrade the
tables without
having to reimport everything.)

I also have a set of stored procedures (insanely complex, but extensively
documented) for placing route markers so that Mapnik can render them, and
a topographic-map rendering that uses the placement.
shows the result. The area that I'm linking to is chosen because it has a mix
of route relations and routes tagged on individual ways, so it demonstrates
that both function.

As far as changes to osm2pgsql go, i looks as if the top-level relation table
 can be handled with fairly light mods to the pathway that imports 'point',
'line', 'polygon' and 'roads'. It essentially could use the same sort of
conversion rules for tags. The big difference is that a relation would have
no geometry.  (This similarity extends to the Lua code for filtering objects,
as well, which appears to be relatively ignorant of geometry in any case.)
The relation-member table is its own sort of object. It has no properties
other than 'role', and it must be populated for everything that's in the
relation table, so there's really no opportunity for fine control the way
we do with tagged objects; a member will either be included (because
its relation is) or not.

It's still a bit of a daunting prospect for me, because I'm not yet
intimately familiar with the code, and there doesn't appear to be
a simple 'road map' for what happens where. If your're amenable to
pull requests for simple improvements to commentary, I'll certainly
try to document what I learn as I learn it.

My understanding is that Sarah 'lonvia' Hoffmann has a very
similar structure underlying the rendering on,
but I've not examined her code.

Tagging mailing list

Re: [Tagging] Traffic sign direction tagging..

2018-09-29 Thread Kevin Kenny
On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson  wrote:
> I'm still against using forward/backward on nodes, it really feels like a 
> hacky way to avoid using a relation (up there with using ref=* on ways to 
> describe routes), which would disambiguate things without being so brittle 
> just because a way reversed, and handle more complex situations like "right 
> turn permitted without stopping" sign below a "stop" sign, or allow a data 
> consumer to be able to display a diagram indicating which ways a stop applies 
> to (handy if you encounter, say, a six way intersection with a four way stop).
> I honestly don't understand why, ten years since it's introduction as OSM's 
> third basic primitive, there's still this weirdly unnatural aversion to 
> relations, even though they're quite a powerful primitive in our toolbox.

I agree with you that we need to design relations for the complex
cases such as what you describe, but I've no problem with the 'hacky'
approach as well - on the principle of 'make simple things easy and
complex things possible'. JOSM (and from what I understand, iD, but I
rarely use it) handles directional nodes on ways fairly competently,
detecting that the mapper is reversing a way that has such nodes
attached and asking what to do about them.

As far as the aversion to relations goes, I think a big part of it is
simply that the downstream support just isn't there.  The tools do
multipolygons fairly well, but that is the only relation that is
really handled well. A bit part of that is that once OSM data has been
through a stock osm2pgsql, there are no relations any more.
Multipolygons become first class objects, and all other relations are
handled at best by devolving their tags upon their components.

(The rest of this message is off the topic of stop signs.)

You raise the issue of ref=* on ways, and why we still use it. That's
a clear case where we use it because the downstream systems can't do
route relations.  I've been trying to help with this - at least to the
extent of trying to revive Phil! Gold's route relation processing. My
version is at, and you can see
one rendering with shaped shields based on relations at
That link is chosen to illustrate an area that intermixes 'tag on way'
with 'tag on relation'. Unfortunately, my time is limited, so the
project has stagnated for a few weeks.  I've not given up, though; the
next task will have to be to generate a pull request to adapt
osm2pgsql optionally to preserve relations, with two new tables to
track them.

Alas, I don't have much hope that the pull request will be accepted.
I've asked the upstream developers several times if they could
possibly review the proposed functionality (I've at least a draft at a
formal proposal -
so that I can know whether I'm entirely wasting my time. I've heard
nothng but silence.

This silence is understandable. The developers are very, very busy,
with much more urgent issues to address. I've not yet advanced the
idea far enough to merit their attention. But at some point, I will
have to conclude that further advances will simply cost me too much in
time and money to be worth risking, because a likely outcome is that
when I do get someone's attention, the whole idea will be dismissed
out of hand.

Tagging mailing list

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

2018-09-28 Thread Kevin Kenny
On Fri, Sep 28, 2018 at 1:38 AM Dave Swarthout  wrote:
> The discussion about the definition of "reach" is interesting but IMO it's 
> slightly off topic.  Perhaps, because of those differences in its 
> interpretation, we would be best served by not using the term at all.

Except that I would like to see flowlines in the US tagged with their
'reach code', which is a numeric identifier in NHD and other sources
that is intended to serve as permanent idenfitication for a particular
waterway. Those cross reference to enough places that carrying the
information is useful.

Tagging mailing list

Re: [Tagging] Traffic sign direction tagging..

2018-09-28 Thread Kevin Kenny
On Fri, Sep 28, 2018, 5:34 AM Marc Gemis  wrote:

> I still highway=give_way and highway=stop with
> direction=forward/backward (which is used by OsmAnd AFAIK).

Me, too - I went around my neighbourhood last year adding them. OSMand does
indeed recognize them.

Describing what a driver might see when approaching a turn would be an
effective use of traffic_sign, but 'node near the way' is pretty useless
for routing. For maximal detail you'd need both, but if you're only going
to add one, the highway=stop is far more useful.
Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Topographic Prominence

2018-09-25 Thread Kevin Kenny
I don't actually mind 'natural=peak' for any named local maximum
elevation. 'Peak' in one of its senses simply means the high or most
important point of anything. You can speak of the peak of a hill, or
of the peak elevation in a region, or talk of a mountain that has
several peaks.

I wouldn't like using 'mountain' to mean 'hill', but 'peak' is more generic.

I'm also fine with 'hill' if people want to use it. But as I said, the
difference between 'mountain' and 'hill' is a matter of local culture.

On Tue, Sep 25, 2018 at 9:19 AM Martin Koppenhoefer
> sent from a phone
> On 25. Sep 2018, at 02:15, Joseph Eisenberg  
> wrote:
> The page for natural=peak lists natural=hill as a tagging error:
> It should better reference the hill proposal as “see also”. While there is 
> likely discussion to be held about hills, simply calling it an ‘error’ is not 
> productive.
> While this “possible tagging errors” section has some sense in pointing out 
> typical spelling errors and expected low usage synonyms, I find it more often 
> than I’d like, overshooting the mark by discouraging new tagging ideas and 
> dismissing tags with (at least slightly) different semantics.
> Please look at these and remove tags from this section when you feel they are 
> not actually “tagging errors”.
> Cheers,
> Martin
> ___
> Tagging mailing list

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Topographic Prominence

2018-09-24 Thread Kevin Kenny
On Mon, Sep 24, 2018 at 10:25 PM John Willis  wrote:
> it would be nice if there was a "caldera relation" to connect them all
together, which would allow the rendering of the named, yet overall
unimportant =peaks to be reduced.

The idea of a relation that would link a peak to its key col and line
parent would do nicely for that.  All of the peaks around a caldera, except
for the highest, are going to be subsidiary peaks, directly or indirectly,
of the true summit.

I live in country with long ridges, and almost anything with enough
isolation and a little bit of prominence winds up being a named summit.
Otherwise, you would get into the situation where you call everything a
subsidiary peak, and that doesn't feel quite right on a ridge like this.

And there are clusters like this one: One of those has over 600 m of
prominence. The one next to it has about 60 m of prominence. Which is
which? The elevations of the summits differ by less than 10 m. (The locals
count them as distinct peaks.)

I'm fine with listing prominence, so that renderers can decide for
themselves what's 'significant', but I think that to distinguish 'mountain'
from 'hill' we need to leave the final decision to the locals.
Tagging mailing list

Re: [Tagging] Topographic Prominence for Peaks

2018-09-23 Thread Kevin Kenny
On Sun, Sep 23, 2018 at 9:29 PM Bill Ricker  wrote:
> This all seems like highly specialized, technical data that is not of
> general interest, as no one but peak-baggers understand the technical
> definition. Many map users seeing this prominence=999m factoid would
> jump to the incorrect conclusion that it was relative to where the
> (lower of the) watershed(s) drains the mountain and thus a synonym for
> the net rise from the valley.(Which is what i read the original post's
> introductory remarks as meaning until I read further and got to the
> technical definition.)

"The (lower of the) watershed(s) that drains the mountain" is
a phrase with unclear meaning.  If by that you mean the highest
origin of a stream on the mountainside, that's usually pretty high
up. If you mean "the bottom of the deepest nearby valley",
how far downstream do you go, and how do you define where
to stop? It's very hard to come up with a coherent, objective
definition that stops short of "sea level".

For mountains that are close to higher mountains, the prominence
is almost always "the height of this mountain above the
highest pass on any side", which is as good a definition as
any. For mountains that are the highest in their ranges, the
prominence is, as you might expect, roughly "the
height of this peak above the surrounding plain".

The only thing that is "highly technical" is that it is quite difficult
to come up with a definition for topographic prominence with
the necessary mathematical rigour to make it objective.

If you look at a list of mountains of the Earth having the highest
prominence, and compare it with the list of the highest elevation,
you will see that prominence actually does a fairly good job at
capturing "local importance:"

By elevation:
1. Everest
2. K2
3. Kanchenjunga, India/Nepal
4. Lhotse I, Nepal/Tibet
5. Makaku I, Nepal/Tibet
6. Cho Oyu, Nepal
7. Dhaulagiri, Nepal
8. Manaslu I, Nepal
9. Nanga Parbat, Pakistan
10. Annapurna I, Nepal
11. Gasherbrum I, Pakistan/China
12. Broad Peak, Pakistan/China
13. Gasherbrum II, Pakistan/China
14. Shisha Pangma, Tibet

By prominence:

1. Everest
2. Aconcagua (High point of S. America)
3. Denali (Mt. McKinley - high point of N. America)
4. Kilimanjaro (High point of Africa)
5. Cristobal Colon (High point of Colombia)
6. Mt. Logan (High point of Canada)
7. Pico de Orizaba (High point of Mexico)
8. Vinson Massif (High point of Antarctica)
9. Puncak Jaya (High point of New Guinea)
10. Mt. Elbrus (High point of Europe)
11. Mont Blanc (High point of the Alps)
12. Damavand (High point of Iran)
13. Kluchevskaya Volcano (High point of Asian Russia)
14. Nanga Parbat (High point of Pakistan)

The first list is confined to the Himalayas, and contains many
relatively obscure entries. The second list has peaks on every
continent except Australia, and consists entirely of
"This is the highest point in (major geographic feature)"

In any case, topographic prominence is very closely related
to the theory of surface network modeling, which in turn ties
closely into research into the representation of terrain with
as few data points as possible.

> Is the OSM primary DB the right repository for this?
> Have we accepted being the repository for everything that anyone wants to map?
> (I don't remember hearing a change from "no".)

Do we really want to get into the argument that objectively
verifiable attributes of real-world features should NOT be mapped
because they are not of sufficiently general interest?
"Objectively verifiable," "actually representing objects
in the field," and "obtainable by direct survey or
from license-compatible data sets" are already a high bar.
I had not heard that the decision of what may be mapped
also has to win a popularity contest!

It isn't a very long step from saying 'topographic prominence
should not be mapped because it is of interest only to mountaineers'
to saying 'hiking trails should not be mapped because they are of
interest only to hikers', or 'navigational aids on waterways should
not be mapped because they are of interest only to sailors.'
'Radio repeaters should not be mapped because they are
of interest only to Amateur Radio operators." "Specimen trees
should not be mapped because they are of interest only
to conservationists." Where does it end?
Do we need to start conducting a census of OSM users to
determine whose interests are important enough to include?

I'm sorry, but to me, your message comes across as
saying, "this thing does not interest ME and I misunderstood
it at first reading, therefore YOU may not map it and must
go elsewhere." That's a positively insulting message to be

Tagging mailing list

Re: [Tagging] Topographic Prominence for Peaks

2018-09-23 Thread Kevin Kenny
On Sun, Sep 23, 2018 at 5:40 PM Joseph Eisenberg
> Yes, “prominence” here is a technical term that has only a partially 
> connection to the subjective “importance” of a peak.
> In general, all peaks with high topographic prominence are considered 
> important by local people (if anyone lives near them) and mountain climbers, 
> but some peaks with low topographic prominence are also well-known, eg the 
> Matterhorn.
> I see that the old, abandoned proposal also suggests the possibility of 
> making a relation to show the parent peak and key col. These sort of 
> relations may not be useful to data users, but they might help other mappers 
> to verify the prominence data.
> Personally, I won’t add new relations when the key col and parent peak are 
> close by, but I will if they are far away.

Exactly. None of our data model is set up to say, "you must map all
features of a given place." It's more, "if you're mapping *this*,
consider mapping *that* as well, and here's how to represent it."

And yes, when key col and parent peak are distant, it gets weird. As a
quick test, I looked up Slide Mountain in the Catskill Mountains of
New York elevation 1276
m, prominence 1000 m. I would have guessed that its line parent would
be on the way to Killington Peak, Vermont, which is both the
nearest higher peak and the nearest more prominent peak, but in fact,
the deep valleys of the Hudson and Mohawk rivers mean that the line
leads away, with a key col somwhere near and the next
higher point being an insignificant knoll in the Monongahela National
Forest in West Virginia. Who knew?

By contrast, it mighn't be worthwhile mapping the key col and line
parent for Hunter Mountain - its parent is Slide
Mountain (link above) and the key col is somewhere in the pass near
the Bellearyre ski resort

In any case, the point remains that topographic prominence is a
completely objective metric; it can be computed from a sufficiently
accurate DEM; but is computation is sufficiently onerous that it's
worthwhile capturing and recording the results.

Tagging mailing list

Re: [Tagging] Topographic Prominence for Peaks

2018-09-23 Thread Kevin Kenny
On Sun, Sep 23, 2018 at 9:34 AM Michael Reichert  wrote:
> (1) If you assume the earth to be a plane, just order the peaks by their
> elevation. It's so simple that I don't give the necessary SQL query
> here. If we used a prominence=* key, it would have to be the distance to
> the next higher peak. If the value were not a number but a term like
> "most_important", "very_important", "neighbour_of_highest" etc. it would
> not comply with the verifiability requirement of OSM and invite people
> to have edit wars.

This misunderstands the concept of topographic prominence.  A peak's
parent in the prominence hierarchy is not the nearest higher peak. It's
the higher peak for which the least descent is required from a given peak
a path that joins them can begin a continuous ascent to the higher peak.

> (2) If you assume the earth to be an ellipsoid, it is more difficult but
> still achievable with ele=* tags in OSM and elevation raster data (SRTM
> etc.) only. There is an open source solution to do so.
> (mentioned in WeeklyOSM issue 423)

That is correct - but SRTM is of insufficent resolution for an accurate
prominence calculation, and the calculation is extremely expensive for
an extremely prominent peak, where the key col can be hundreds or
or thousands of km away. It's worth precomputing and tabulating.

> (3) If we use a tag like prominence=* for peaks two mappers will have a
> different opinion on the value to choose. For example, the Matterhorn is
> 4478 m high but Monte Rosa is 4634 m high and not that far away.
> However, the Matterhorn is more famous and people expect it to appear on
> maps at the same or lower zoom scales than Monte Rosa. Whose opinion is
> correct? From my point of view, the mapper using the elevation only
> because that is the only verifiable fact while the prominence in
> advertisement is something we don't record in OSM for a very good
> reason. (Please replace "peak" by "city" and "height" by "population"
> and read this paragraph again)

Topographic prominence is entirely objective; it's a well-defined
numerical quantity. It is not to be confused with social prominence.
Sorting peaks by topographic prominence at a low zoom level would
be an interesting idea, It would surely not fix the 'Matterhorn'
vs 'Monte Rosa' problem, but it might well help the situation
where a low-zoom map shows rather insignificant subsidiary
mountains rather than the prominent peaks of a range.

About all that I'd have to say about the proposal is that it
would be useful - and would probably need a new type
of relation - to tabulate key col location and parent peak
as well as prominence.  The relation would have three
parent_peak - A point object representing the parent peak
subsidiary_peak - A point object representing the subsidiary peak
key_col - A point object representing the key col
and be tagged 'type=topographic_prominence'.
The prominence of a subsidiary peak can then be
deduced by subtracting the key col elevation from that
of the subsidiary peak. (Alternatively, 'prominence='
could be added as a tag on the relation, but that's rather a
redundant representation.)

Tagging mailing list

Re: [Tagging] Mapping language borders, tagging offical languages?

2018-09-20 Thread Kevin Kenny
On Thu, Sep 20, 2018 at 9:55 AM André Pirard 

> Belgium speaks 3 official languages and their very official borders *have
> been* mapped.
> This subject was presented several times on this list and "raised" a total
> lack of interest.
> Especially regarding the need to define a language boundary type.
> The most similar country regarding languages is Switzerland.
> But they did not care to define borders, AFAIK.
> Same for USA, Canada, etc.

"Did not care to define" is an odd way of putting it. USA cannot map
official language borders because USA has no official language or
languages. The majority language is, obviously, US English, but there is no
legislation making it official nor requiring government business to be
transacted in English. We also have a long and ugly history of nationalists
suppressing minority languages, but generally speaking, the laws that the
nationalists claim to be enforcing do not exist. "English as official
language" legislation has been introduced in virtually every session of the
Congress, and has never passed. The movement to make English official goes
all the way back to 1780, even before the war of American independence was

I suppose one could tag 'official languages' of  US jurisdictions that sort
of have them. Until recently, California and Massachusetts had laws on the
books requiring public schools to teach classes only in English. (Arizona
still does, but California and Massachusetts repealed their laws in the
last couple of years and have reinstated bilingual education.) Dade County,
Florida had a well-publicized local law that forbade transportation signage
in any language but English, requiring Spanish-language signs to be taken
down. About half the states have laws requiring that the edicts of
government must be published in English (but not requiring that it be used
to the exclusion of other languages). Nebraska's legislation after the
First World War had the effect, briefly, of banning all foreign-language
instruction in the state's schools (and Heaven help those who wished to
prepare for travel abroad!).

It is true that in the US, one can expect to find street signs in English
(augmented possibly with one or more minority languages), but that is
usually a matter of practicality rather than formal policy.

I suppose that one could also, as an example, draw an official language
border around the Navajo Nation and indicate that Diné bizaad and Spanish,
as well as English, are official languages of its government, but that
again opens the whole debate about how to domestic dependent nations, and
it is accurate to state that I don't care to reopen that debate today.

Best regards / meilleurs voeux / (sorry, I don't speak Flemish)

Tagging mailing list

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-19 Thread Kevin Kenny
On Wed, Sep 19, 2018 at 4:34 PM Tobias Zwick  wrote:
> 2. US interstate in Montana (US-MT):
>  highway=motorway + source:maxspeed=US-MT:interstate
>  highway=motorway + maxspeed:signed=no + ref~^I
>(maybe ref-starts-with-"I" is not necessary because all interstates
> are tagged as motorways?)

Not all Interstates *ought* to be tagged as motorways. A case in point
is Interstate 93 in Franconia Notch, New Hampshire, which *ought*
to be a trunk (it's a two-lane road with a centre guard rail that was added
long after the initial construction.)

Many motorways are not Interstates. The local law where I live doesn't
special-case Interstates, but rather uses phrasing like 'multi-lane
grade-separated controlled-access highways'.

But that said, if a piece of legislation says, 'Interstate', then it means
specifically 'Interstate', whether motorway or not, and not other motorways.

Tagging mailing list

Re: [Tagging] landuse for government offices ?

2018-09-19 Thread Kevin Kenny
What appears to be practice here, although I have only a few mapped
examples, is to have office=government appear on the (multi)polygon
representing the grounds, and not just on the building. I concede that
if you have a single large campus with offices of many agencies, the
subtags don't work, so I'm not opposed to a new tag for the landuse.
I'm simply concerned whether the handful of local examples that I
managed to turn up were mistagged.

The landuse also is perhaps better in that it's a more appropriate tag
for 'government' facilities such as a highway maintenance garage. In
some of the villages around here, the highway maintenance, police,
fire brigade, and village government are all in the same building.
I've paid a traffic ticket in front of a justice of the peace who was
seated at a judge's bench in the corner of a firehouse, with the
engines backed out into the car park while court was in session. Got
to love a village of four hundred souls in the middle of nowhere.
On Mon, Sep 17, 2018 at 1:35 PM OSMDoudou
<> wrote:
> Hello,
> The "landuse=commercial" page [1] says "area may consists of offices,
> administration", whereas the "landuse" page [2] says "Government services
> and businesses should not use this tag".
> How to tag a piece of land where governmental several office buildings are
> situated ?
> For example, a set of Service Public Fédéral (SPF) buildings, which are
> government offices. [3]
> [1]
> [2]
> [3]
> ___
> Tagging mailing list

Tagging mailing list

Re: [Tagging] Watershed or Drainage Basin relation draft proposal

2018-09-13 Thread Kevin Kenny
On Thu, Sep 13, 2018 at 10:02 AM Martin Koppenhoefer

> you’ll have to put the ridges to map the watersheds anyway, the catchment 
> basin is implicit with the waterways, coastlines and ridges.
> If there are names or other properties for the watersheds and catchment 
> basins in play, it could make sense to have dedicated objects nonetheless, I 
> agree.

> >
> > 2), while a ridge has to have a certain amount of slope to be called a 
> > ridge (perhaps at least 5 or 10% grade?), watershed boundaries are 
> > sometimes very shallow
> how can we observe those sheds in shallow areas? Can it be done on the ground 
> or does it require additional elevation data? Maybe in the context of shallow 
> land the sheds aren’t stable?

Definitely there are exorrheic wetlands and ponds in which the
watershed line is entirely indefinite. I know of a number of wet areas
that have distributaries into multiple major river basins; e.g., the
Grand Gorge area in the western Catskills drains into both the
Delaware and the Schoharie (and thence via the Mohawk to the Hudson);
the Preston Ponds area of the Adirondacks drains to both the Hudson
and to the Cold River (thence by the Raquette to the St Lawrence), and
so on.

The nearest the US has to an authoritative source is the National
Hydrography Database (NHD) which does have watershed boundaries, with
a hierarchical reference numbering system identifying them and tying
them to the 'reach codes' of the rivers that drain them. ('Reach code'
is a persistent identifier of up to 16 (?) digits, identifying
branches of a river from mouth to headwaters. (I've never investigated
what reach codes do with distributaries - I simply haven't needed to

There have been projects in the past to import NHD data in bulk.  I
was tempted to do it in my area once - I have the good fortune of
living in a place where the data quality of NHD is pretty good. While
some bulk imports from NHD have been highly successful, I stumbled on
conflation issues and abandoned the idea. I still occasionally
copy-n-paste a stream from NHD into JOSM, but that's always
onesie-twosies, and compared with data that are already in OSM and
with aerials. (Severe storms in the last decade or so have caused some
fairly major watercourses around here to shift, and NHD still hasn't
caught up.)

Tagging mailing list

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

2018-09-13 Thread Kevin Kenny
[Off list, I've had my say on list]

> In the past, it was decided that the coastline would represent the high
tide line, and the first OSM mappers generally put the coastline up at the
tidal limit of rivers (which were easy to verify for them, because there is
usually a dam or weir at that location in England).

That's entirely sensible for Great Britain.

And it matches my local situation, except for where the coastline is drawn
- and for the immense scale of the difference.  The Hudson River (and the
problem repeats itself for rivers such as the Delaware and Susquehanna) has
an extremely long estuary. It's really unclear that the English rule makes
sense for it. That's why I've been arguing for leaving room for a modicum
of judgment on the part of the local mappers.

The Hudson is definitely estuarine, with tidal ranges up to a couple of
metres, for its entire lower reach.  The traditional 'mouth' of the river
is an east-west line from the Battery, the southern tip of Manhattan
Island, and this is labeled as 'mile zero' by the boatmen. The river
continues to be tidal, flowing about six hours onshore and six hours
offshore, all through its lower reach. Even in a dry summer, it's virtually
never 'salt' (defined as 100 mg chloride per litre) in surface water beyond
mile 60 (kilometre 97), although denser salt water persists at depth
farther up. The salt front has not, in living memory, retreated past mile
75 (kilometre 121) - above there, it can be thought of as being perennially
fresh water, although continuing to reverse direction above that point.

As I said, the flow is about equally divided in terms of time, but the flow
rates on ebb and flow vary widely - the river water, after all, does
eventually reach the sea. By Haverstraw (about 60 km from the river mouth)
the ebb runs about twice as fast as the flow, and that's as far upstream as
tidal currents present a navigational hazard. (Canoeists and kayakers had
better be aware of the direction of the tide, since few can make progress
upstream paddling against a Hudson River ebb!)

The river remains navigable by moderately-deep-draught vessels all the way
to Albany. A Super-Panamax or larger ship cannot use Albany as a port of
call, but the Port of Albany does see a fair amount of oceangoing traffic.
It can accommodate a ship 289 metres in length, 33.5 metres in width, and
9.5 metres in draught. Its fixed cranes can lift 225 tonnes, and 1000-tonne
barge-mounted cranes are available. Still, it's unquestionably a riverport
- the draught of a ship has to be de-rated for the fresh water, and it's a
long sail up to there. It's chiefly used for bulk cargo from upstate New
York and neighbouring Canada, and for project cargoes such as heavy
electrical equipment from GE Energy in Schenectady.

Most of the lower reach of the Hudson has very little tidal change to its
spatial extent. It's in a narrow valley between two highlands, and both
banks are cliffy.  (The view across the river from Manhattan is quite
spectacular.) The water moves up and down, but has little room to expand
from side to side.

The tidal limit is the 'Federal Dam' (actually a weir by OSM definitions,
since there's a full-width spillway) in Troy, so just as in the UK, we have
a well defined fall line marking the transition from estuary to true river
- at river mile 153 (246 km).  The locals think that extending the
'coastline' upriver nearly 250 km from what is traditionally regarded as
the river mouth is little short of insane. Even if you were to place the
'mouth' of the Severn somewhere near Cardiff, for instance, a comparable
distance up the river would bring you, at the very least, well past
Shrewsbury and perhaps even to the headwaters. Great Britain simply has no
estuaries of nearly that magnitude.

All this leaves me with no clue, in OSM terms, what to call the thing.
Mostly, I don't call it at all. It might answer. :)

On Thu, Sep 13, 2018 at 3:42 AM Joseph Eisenberg 

> Re: "Data consumers have a right to being able to interpret the data as
> the mapper intended"
> For data users, it would be most useful if the coastline is in a
> consistent position in relation to the sea and land, clearly.
> In the past, it was decided that the coastline would represent the high
> tide line, and the first OSM mappers generally put the coastline up at the
> tidal limit of rivers (which were easy to verify for them, because there is
> usually a dam or weir at that location in England).
> But perhaps we need to start adding second line to represent the average
> low tide, to define the intertidal zone. Right now the only way to see if
> an area is in the intertidal zone is if a natural area has been tagged
> outside of the coastline. This works for shoals, beaches and wetlands, but
> it's a little ambiguous. If we start mapping the low tide line, this will
> clearly show the interidal zone. This outer line could also be defined to
> cut across rivers and estuaries at the mouth, similar 

Re: [Tagging] Slow vehicle turnouts

2018-09-10 Thread Kevin Kenny
> On Mon, Sep 10, 2018, 14:36 SelfishSeahorse  wrote:
>> I wasn't aware that it is allowed to cross a single solid line in the
>> USA. Hence forget the overtaking:lanes:=* tags in
>> the example in my last message.

On Mon, Sep 10, 2018 at 3:48 PM Paul Johnson  wrote:
> It's a recentish (late 90s/early 2000s) update to the MUTCD, before that you 
> would be correct (and usually as a stopgap between striping, places where 
> this is still the case is highlighted by signage, but this is getting to be 
> rare as most plsces have had long enough to require a repaint if not a repave 
> since then).

The states have had considerable leeway in how they mark their own
highways (the Federal government has control only on the highways that
it funds).  New York has used a single solid white line to mean 'lane
crossing discouraged but not prohibited' for the 45 years that I've
been driving here. Prohibited lane crossings have, for at least that
long, been set off by double lines or by partial-barrier lines with
the solid line toward the lane that must not be departed from.

I seem to recall that the meaning of a single solid yellow line has
varied from 'crossing discouraged', to 'crossing forbidden but left
turns permitted', to 'crossing prohibited'. The current drivers'
manual states that they have the same regulatory effect as a double
yellow line. (Left turns across a double yellow are permitted only
when they can be accomplished without impeding traffic in either
direction and only into private driveways, entrances and alleys.) The
only single yellow center lines I've seen in the last couple of
decades have been on private roads, where they mean, 'the owner was
too cheap to shell out for enough paint for standard markings.'

Tagging mailing list

Re: [Tagging] Slow vehicle turnouts

2018-09-10 Thread Kevin Kenny
On Mon, Sep 10, 2018 at 2:38 PM Paul Johnson  wrote:
> I see it as a variation on no turn on red/turn after stop OK on red 
> dichotomy.  Not really significant enough to bring up in the map data 
> specifically, so long as the signal itself is mapped.  And the single white 
> line seems to not be of special significance in most cases, only meaning that 
> you need to use additional caution when changing lanes (as opposed to double 
> white lines, where lane changes in one or both directions is prohibited).

For what it's worth, New York appears to have used a double broken
white line to separate climbing lanes. (Source: personal observation
in the field.) The drivers' manual does not discuss this unusual
marking. There is a subtle difference in the signage. The signs read
EXCEPT TO PASS" for a 'normal' multilane road. The implication appears
to be that you don't have to move to the right into a climbing lane if
nobody is overtaking.

The double-broken-white-line convention last appeared in the 2005 NY
State MUTCD. There's a 2015 order
that prohibits the practice, and uses broken, solid, and double white
lines to indicate that lane crossings are permitted, discouraged or
prohibited respectively - in conformance with the federal MUTCD.
Nevertheless, there are a fair number of roads that have not been
restriped and still bear the old double-broken-line convention.
Restriping projects in some cases appear not to have removed the old
paint, giving rise to a broken white line that is unusually wide.
MUTCD permits painting wider lines than standard, for emphasis. New
York uses the wide lines to set off dedicated lanes (HUV lanes,
turning lanes, merge/exit lanes, or lanes committing the driver to one
side of a route split.)

There were also once some lanes that were set off with white
partial-barrier lines (broken and solid line in parallel), which
appeared to allow merging into a climbing lane but forbid leaving one
once committed to it. These are also forbidden under the 2015 order.

A 90%-good solution to all of these combinations is simply to indicate
the number of forward, backward and both_ways lanes. Some of the finer
details fall into "Don't map your local legislation'

Tagging mailing list

Re: [Tagging] Slow vehicle turnouts

2018-09-10 Thread Kevin Kenny
It seems to me that the key attribute of the 'climbing lane' situation
that Dave mentions is that it's an additional lane. It's provided for
slow-moving vehicles, sure, but that's really a special case of the
near-universal convention that slow-moving traffic gives way to
overtaking traffic by moving to the outside (that is, in North
America, to the right). The difference, at least where I am, between a
climbing lane and another ordinary lane is a subtle one: you don't
have to move to the outside if nobody's trying to overtake, rather
than a "keep right except to pass" rule. You get 90% of the way there
by simply having the correct number of lanes:forward and
lanes:backward. Is adding a lane that much more complicated than
drawing a parallel way?
On Mon, Sep 10, 2018 at 11:31 AM Joseph Eisenberg
> I'd say that it would be better to leave them unmapped than to incorrectly 
> map them as separate service roads.
> If they are only divided by a single painted line, they are just lanes, not a 
> separate roadway.
> And it's not too difficult to split the way twice and paste on a couple of 
> tags
> On Mon, Sep 10, 2018 at 10:17 PM Dave Swarthout  
> wrote:
>> Wow, thanks for the help, Markus. I really appreciate it.
>> But I must say, if I have to use that method to tag all the turnouts on the 
>> Sterling Highway, I'm going to leave them unmapped. Life is too short and 
>> there is a lot of other mapping yet to do in Alaska.
>> Although these lanes are not physically separated by a barrier other than a 
>> painted line, I'm going to opt for the service road scenario. It is simple, 
>> much, much less error prone to map, and IMHO, would do the job better than 
>> the lanes technique.
>> Thanks to all,
>> Dave
>> On Mon, Sep 10, 2018 at 6:51 PM SelfishSeahorse  
>> wrote:
>>> On Mon, 10 Sep 2018 at 11:17, Dave Swarthout  
>>> wrote:
>>> > I'm still not convinced the lanes:smv tagging scenario is the best 
>>> > solution but were I to change my mind, how would I tag my turnouts?  Here 
>>> > is another screen shot of the particular section of highway with a 
>>> > turnout on both sides of the road that I've been discussing (59.752103, 
>>> > -151.766395 ) with the ways removed for clarity: 
>>> >
>>> I would probably split the road at every place where an additional
>>> lane begins or ends, i.e. four times, and would tag the sections as
>>> follows from right to left (this is the direction of the highway way):
>>> lanes=2
>>> lanes=3
>>> lanes:forward=2
>>> lanes:backward=1
>>> smv:lanes:forward=|designated
>>> overtaking:lanes:forward=yes|no
>>> lanes=4
>>> lanes:forward=2
>>> lanes:backward=2
>>> smv:lanes:forward=|designated
>>> smv:lanes:backward=|designated
>>> overtaking:lanes:forward=yes|no
>>> overtaking:lanes:backward=yes|no
>>> lanes=3
>>> lanes:forward=1
>>> lanes:backward=2
>>> smv:lanes:backward=|designated
>>> overtaking:lanes:backward=yes|no
>>> lanes=2
>>> In case the turnouts were separated by a barrier, i think your idea
>>> with highway=service + service=slow_vehicle_turnout would make sense.
>>> Regards
>>> Markus
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at
>> ___
>> Tagging mailing list
> ___
> Tagging mailing list

Tagging mailing list

Re: [Tagging] Is waterway=riverbank an 'Old scheme' ?

2018-09-07 Thread Kevin Kenny
On Fri, Sep 7, 2018 at 5:16 PM François Lacombe
> Le ven. 7 sept. 2018 à 21:40, Richard  a écrit :
>> > The idea that  waterway=* must be routable is, frankly, a new one to
>> > me.
>> that idea is nonsense.. there was never the assertion that 
>> waterway=ditch,stream
>> be navigable.
> That escalated quickly !
> Routable doesn't mean navigable at all. Hydrographic routable network is 
> about where the water goes.
> Ditches, canals and river where the same property to carry water somewhere.
> You're so focused on particular usage that anything else is non-sense. This 
> is really questionable.
> We'd really better to separate concepts in different keys between water ways 
> and other features like dams, fuel places or piers which doesn't carry water 
> at all.

OK. you're asking that 'waterway' be synonymous with 'flowline' -
that's more likely to be observable, but still not something that
we've had a convention for.

We're gradually and indirectly approaching having a 'routable'
hydrography, in your sense. JOSM, for instance, warns if a
waterway=stream or waterway=river is disconnected at its downstream
end. I doubt that we'll ever get to the point where all waterway=*
tags represent flowlines, but one can get a long way by restricting to
'waterway=river' and 'waterway=stream' (note that a waterway=river is
supposed to be kept continuous by following some approximation to the
Thalweg through lakes, ponds, reservoirs). I don't think we yet have a
convention for 'connector' waterways representing the machinery inside
a dam or the unknown path that water is taking through karst terrain.
I think we could, with some effort, come up with a SUBSET of
waterway=* tags that are expected to be topologically consistent. The
use of 'waterway=riverbank', 'waterway=dam', and so on are rather too
well established to undo at this late date.

Not all ditches and canals have a well-defined direction of flow. I'm
not sure what approach the hydrographers would take to the stretch of
the modern Erie Canal between locks 20 and 21, where it's higher than
the adjacent reaches in both directions (the 'downstream' end drains
eastward toward the Mohawk River, and the 'upstream' end joins Fish
Creek, which flows west into Oneida Lake. I presume, also, that
hydrographers have recognized conventions for dealing with nearly flat
regions where the water doesn't know *which* way it wants to go. The
Preston Ponds in the Adirondacks, for instance, have distributaries in
both the Hudson and Saint Lawrence basins.

I think that if we recognize that not all waterways are flowlines, but
that some waterway=* are expected to be, we can make progress with
your idea.

'Routable', in this group, often denotes 'usable by a routing engine
to inform a human of a path to take' - and it's imaginable that
someone might want to design a routing engine for watercraft - that's
why we got confused. Routing in terms of 'finding a way that a
watercraft can take' does indeed imply navigability!

I sometimes generate incomplete hydrographic networks, simply because
I'm drawing stuff that I need for a specific map, and don't bother to
trace everything downstream to a watercourse that's already present in
OSM. That's the sort of thing that is at least correct, if not useful
for hydrography, and another mapper can complete it without needing to
undo anything that was already done. Many of these watercourses are
small streams that I cannot follow through urban areas because I have
no idea where the man-made drainage network takes them.

Tagging mailing list

Re: [Tagging] Is waterway=riverbank an 'Old scheme' ?

2018-09-07 Thread Kevin Kenny
On Thu, Sep 6, 2018 at 6:38 PM François Lacombe
> To me, waterway=* should only get values to map linear water courses for the 
> routable hydrographic network.
> Newer tagging with natural=water sounds ok, except for artificial water 
> features.
> I'm not so keen of natural=water over a man made irrigation canal, unless 
> there is no artificial water, even in artificial man made structures

natural=* is a lost cause, and  part of the issue there is that there
are a good many natural=* tags that don't have neutral equivalents.
There does need to be some way to say, "this land is covered by water
perennially" without asserting who put it there. It's much worse when
it's 'this land is covered by trees.' There is no non-controversial
tag to assert that simple fact. As soon as we start in with the idea
that a reservoir is 'unnatural' water, we give trouble for initial
mapping. I can't necessarily see on aerials whether the pond that I
see has a dam at its outlet, or whether the dam was put there by
humans or beavers, or whether the dam is creating a new impoundment or
merely inducing an insignificant rise in the water level of an
already-existing waterbody.

If a mapper can't say, 'there's water here', 'there are trees here',
'there is grass here' without doing research on human intent and
purpose for the landcover, navigability of the waterways, there's
something wrong with the data model. Those are the bones that
everything else fleshes out. In some of the places I map, there are
still broad expanses of blank areas on the map, where the road network
is hallucinatory, even fairly major watercourses are missing, and
geomorphology is virtually nonexistent. I need a way to sketch in
broad strokes without either telling lies or having to do research
before I even start.

The idea that  waterway=* must be routable is, frankly, a new one to
me.  How is a mapper supposed to tag a non-navigable river? Water
routing sounds like an intriguing idea, but at least so far, tagging
doesn't appear to support it.

To be more specific:

I don't want to stand in the way of that sort of project by mismapping
things, but I frankly don't know how to get it right. I recently
mapped my first river multipolygon (needed it for a large-scale map
that I was rendering), It is most emphatically NOT navigable, but I
added the polygons because it's fairly wide and I wouldn't fancy
fording it in a season of high water. I'll plead guilty to stopping
at, 'induces no warnings in JOSM, and renders correctly on OSM and in
my custom rendering.' I used waterway=riverbank and a multipolygon,
because that appears to be what others used nearby, and I did indeed
try to approximate the Thalweg with waterway=river.

In any case, it would be a very quick thing to change that particular
multipolygon to natural=water water=river. How *ought* the Thalweg be

That particular river drains into a reservoir. At least *some* of its
land area is 'natural' water; there are drowned ponds under there
(whose shorelines could be researched; I have maps from a 1903
survey). But recovering their shorelines hardly seems urgent to me.
Can we agree on some sort of tagging for, 'this is a waterbody'?
That's more observable than, 'this is something Mother Nature put
here' as opposed to 'this is something crafted by the hand of

Tagging mailing list

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

2018-09-03 Thread Kevin Kenny
It would certainly need to be above Haverstraw - the current there
shows significant tidal reversal.  I haven't found a gaging station
farther upriver that reports tidal currents. Croton Point, where the
river broadens to form the Tappan Zee, would probably be the lower
limit. Even that seems unreasonably far upriver.

The tidal range increases as you move upstream from there. The
greatest tidal range in the entire river is at Troy. One Native
American name for the river was "Mahicantuck" which means, more or
less, "the river flows both ways."

The estuarine situation will always be hard to deal with, and I think
we'll simply need to have rough guidelines and then trust the judgment
of the locals.
On Mon, Sep 3, 2018 at 2:51 PM Christoph Hormann  wrote:
> On Monday 03 September 2018, Kevin Kenny wrote:
> > Imagico's proposal is perhaps objective, but surely doesn't match
> > perception in my part of the world. It seems odd that the 'coastline'
> > must extend upward to -
> > but that is, according to Imagico's definitions, simultaneously the
> > lowest and highest permissible limit. [...]
> Then you have misunderstood the proposal.
> With the Hudson river obviously the tidal case applies so you have the
> lower limit as:
> With significant tides the coastline should go upstream at least to a
> point where on waterflow is going downstream for a significantly longer
> part of the tidal cycle than it goes upstream due to raising tide.
> This is evidently always below the upper limit (range of tidal
> influence).
> I can't say for sure where i would place the lower limit in case of the
> Hudson - The Narrows is quite definitely too low - but the current
> closure seems fine.
> For low volume tidal rivers (i.e. without a salt wedge and no
> significant influence of the water volume on the ocean salinity) it
> would also be possible to define the lower limit through salinity (not
> in absolute terms but as a fraction of the open ocean salinity in the
> area).
> --
> Christoph Hormann
> ___
> Tagging mailing list

Tagging mailing list

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

2018-09-03 Thread Kevin Kenny
Imagico's proposal is perhaps objective, but surely doesn't match
perception in my part of the world. It seems odd that the 'coastline'
must extend upward to - but
that is, according to Imagico's definitions, simultaneously the lowest
and highest permissible limit. The locals would be astonished to call
the whole lower Hudson River 'ocean,' even though it is tidal.
Salinity varies; the point at which chloride concentration of 100 mg/l
is observed varies seasonally by over 100 km. There is an observable
salinity gradient through the entire estuary, but anywhere north of,
say, Hyde Park is 'fresh' water by any reasonable definition, even in
a dry summer. Is it reasonable to draw 'coastline' on fresh water?
On Mon, Sep 3, 2018 at 12:05 PM Christoph Hormann  wrote:
> On Monday 03 September 2018, Joseph Eisenberg wrote:
> > In my case, I've been debating whether to change the tagging of the
> > coastline in southwestern New Guinea (Papua, Indonesia) where many
> > large tropical rivers meet the Arafura sea among mangroves. The heavy
> > rainfall in this area means that the rivers have a pronounced
> > current. But the water is brackish and certainly tidally-influenced
> > far inland. Right now, it seems odd that many patches of mangroves
> > are made into "islands" by the use of natural=coastline, though
> > locally they would be considered part of the larger landmass of New
> > Guinea.
> The sitaution at a mangrove coast is slightly different from elsewhere
> because the mangrove forest is typically mapped as land w.r.t. the
> coastline which makes the tidal channels in between look like wide
> rivers - which is however often misleading.
> For example
> is not a river despite being tagged as a riverbank polygon.
> This misunderstanding of the nature of mangrove coasts misinterpreting
> wide tidal channels as large rivers has led for example for some time
> in West Africa to a massive shortening of the coastline and a large
> fraction of virtual closing segments in the total coastline lenth -
> see:
> This is now mostly fixed but the lure especially of armchair mappers to
> map this way is still there.
> > See: ; the
> > coastline is quite noticable because it has also been tagged as the
> > administrative boundary.
> The administrative boundaries are generally a bad place to position the
> coastline because they are typically defined very differently from how
> OSM defines the coastline (and are also mostly very inaccurate
> geometrically).
> > What will be most helpful for data users and map renderers? Should
> > the coastline extend inland many kilometers, to where the mangroves
> > end? This will create a large number of apparent islands, and small
> > rivers will be entirely part of the "ocean" beyond the coastline.
> > Should it be down the the mouth of the river, to keep the coastline
> > as compact as possible?
> The coastline should be (a) a meaningful geometry on its own, i.e. the
> virtual parts of it (closing segments at river mouths) should be short
> and (b) be as easy to verify for the mapper as possible.
> Technically it is also important that the range of acceptable coastline
> positions is not too large so mappers do not move around the coastline
> a lot just to scratch their personal itch.
> > What about huge estuaries like the Saint Lawrence and the Rio De La
> > Plata? Should there be a vote on Imagico's proposal, or a new
> > proposal?
> I would be glad if anyone wants to reactivate the proposal or comes up
> with simpler rules for where to close the coastline.  But IMO a hard
> requirement for this would be that these are physically based rules
> rooted in the observable reality and not based on political or other
> purely abstract considerations.
> Some newer examples of problematic closure placements (in addition to
> the ones in the proposal):
> --
> Christoph Hormann
> ___
> Tagging mailing list

Tagging mailing list

Re: [Tagging] why do we discourage leisure=skatepark/skate_park?

2018-08-30 Thread Kevin Kenny
On Thu, Aug 30, 2018 at 3:11 PM Paul Allen  wrote:
> On Thu, Aug 30, 2018 at 7:50 PM, Martin Koppenhoefer  
> wrote:
>> Once again I stumbled across a warning which discourages these 
>> leisure=skate_park and skatepark on the sport skateboard page because of low 
>> usage, but with the only alternative “pitch”. If you can speak about pitches 
>> in this context, I would expect a skatepark to often consist of more than 
>> one “pitch”.
> I'd expect a pitch to be flat.  I'd expect a skateboard park to not be flat.  
> Cricket might turn into an interesting sport if
> played on a skateboard "pitch" but I doubt it will ever happen (cricket's 
> function is an excuse for people drowse in the
> sunlight).
>> My preference is for skatepark without the underscore, seems most used 
>> although currently not in osm ;-) (look at tag history to see automatic 
>> changes resetting it, numbers are very low, certainly discouraging the tag 
>> doesn’t help)

An alternative might be leisure=sports_centre, sport=skateboard ?
That's what I had understood to be the preferred tagging. (But what do
I know? I've never mapped one.)

Tagging mailing list

Re: [Tagging] horse mounting/dismounting steps

2018-08-28 Thread Kevin Kenny
On Tue, Aug 28, 2018 at 9:55 AM Philip Barnes  wrote:
> They are not beside bridleways, they are typically part of the front 
> structure of buildings of an age that means they are automatically grade II 
> listed buildings. Standalone ones are also of an age that they will be 
> protected. They are invariably within conservation areas.
> I would maintain they are historic features of interest and not a part of 
> modern horse riding.

Consider also the scene at,5187562.211271851,-8262985.673109871,5187771.815935289=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache

The most obvious man-made objects in that clearing are a cabin (home
to the fire warden back when the place was staffed - it was
decommissioned in the 1970s), a lookout tower, a picnic table, an
outhouse, and, to the northeast, a mounting platform. People with
mobility impairments who are at least able to stand and pivot can use
the platform to mount a horse from a wheelchair (which can then be
loaded aboard a pack animal). This is part of a state program for
wilderness access for persons with disabilities.

I haven't tried to map the platforms. It's been a few years since I
was up to the summit of Hunter Mountain. The tower has terrific views,
but the trails tend to be crowded (well, by the standards of trails in
a wilderness area :)) in fair weather.

These must be some species of the genus that we're discussing.

Tagging mailing list

Re: [Tagging] Slow vehicle turnouts

2018-08-26 Thread Kevin Kenny
On Sun, Aug 26, 2018 at 4:11 PM Dave Swarthout  wrote:
> >We also have the occasional spot like
> >,5242597.149663145,-8283317.927238801,5242833.029555047=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
> >There, we have an extra lane on the northbound side for the purpose of
> >getting by when the way is blocked by left-turning traffic
> My case is almost identical to the above illustration, except to substitute 
> the words "slow moving vehicles" for "left turning traffic". I reckon I could 
> use the lanes tagging but like Kevin, I have many "other fish to fry" which 
> is why I'm still looking for a simple one-tag-fixes-all solution.

My guess is that the slow-moving traffic is supposed to pull over into
the outer lane, allowing the parade behind to pass on the inside,
rather than the through traffic passing on the outer lane?  That's
like my first case, except that in that particular case, the climbing
lane goes on for several km (the highway is gaining a few hundred
metres of elevation up the Helderberg escarpment). We do have ones
that are more like pullouts rather than long lanes. There's a shorter
one on the westbound carriageway in,5268580.377261018,-8265722.941101252,5269523.896828834=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache

By contrast, although the section is short, the outer westbound lane
is NOT a climbing lane. It's set off by a single broken line, and
traffic is expected to keep to the right except to pass.

Tagging mailing list

Re: [Tagging] Slow vehicle turnouts

2018-08-26 Thread Kevin Kenny
On Sun, Aug 26, 2018 at 2:22 PM Paul Johnson  wrote:
> On Sun, Aug 26, 2018, 12:30 Dave Swarthout  wrote:
>> I agree that those are two different critters and that using the passing 
>> _place tag is not the best way to handle this. But, aside from splitting the 
>> highway into lanes:forward, lanes:backward, etc., how should such a turnout 
>> be tagged? That's the question that led to this thread.
>> highway=slow_vehicle_turnout ?
>> slow_vehicle_turnout=yes ?
> I don't think there's a reason to tag it as anything special beyond just the 
> usual turn lanes tagging, since it's the same situation as any other "keep 
> right except to pass" situation, just shorter.

I *mostly* agree.

Around here, the law doesn't say you have to use a climbing lane
unless you're slow-moving. That's unlike a typical multilane road,
where you are required to keep to the right except to pass. The
posting is different, too: "KEEP RIGHT EXCEPT TO PASS" for an ordinary
multilane road as opposed to "SLOW MOVING TRAFFIC KEEP RIGHT" for a
climbing lane. They're often striped differently, too:,5277161.158511143,-8246672.174938101,5277392.55967092=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
is an example.  (Uphill is to the west.) The resolution on the orthos
isn't quite good enough to show that the rightmost lane is separated
by a double broken line, not just a single one, but you can see that
it looks heavier in the imagery.  That stretch is also signed that
HGV's, buses and trailers are forbidden in the leftmost lane.

We also have the occasional spot like,5242597.149663145,-8283317.927238801,5242833.029555047=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
There, we have an extra lane on the northbound side for the purpose of
getting by when the way is blocked by left-turning traffic. When the
way is clear, it's normal and expected to proceed through the
intersection on the main lane. By contrast, the extra lane on the
southbound side is striped and signed as a dedicated turning lane.

I'd still ordinarily just use the 'lanes' tags and possible turn
restrictions. (If I troubled to tag traffic lanes. Ordinarily, I
don't. I have other fish to fry.)

Tagging mailing list

Re: [Tagging] Slow vehicle turnouts

2018-08-24 Thread Kevin Kenny
On Fri, Aug 24, 2018 at 8:18 PM Dave Swarthout  wrote:
> I've been trying to decide tagging for slow-vehicle turnouts consisting of a 
> lane added to the right side (in the U.S.) of the road so that slow moving 
> vehicles can pull aside to allow following vehicles to pass. The best I can 
> come up with is the tag highway=passing_place but strangely it applies only 
> to nodes. I'm looking for examples from the real world similar to the one in 
> this JOSM screenshot. I've selected both the passing lanes to color them red 
> so you can see them.
> I had been using a variable number of lanes to describe the situation but 
> these two passing_places are offset making using the lanes tags cumbersome to 
> apply, 4 separate pieces, lanes going in different directions, oneway 
> sections, etc. According to the Wiki, the passing_place tag is to be used 
> only on nodes. 
> ( Why this 
> should be so, I do not understand.

lanes:forward=* and lanes:backward=* is the best that I've found so
far to describe truck climbing lanes and similar features. They don't
appear in your image to be grade-separated, so they don't need to be
separate ways - one way for each section of the road, with appropriate
lanes:forward and lanes:backward appears to describe what's on the

Tagging mailing list

Re: [Tagging] use of points even when it clearly defines a building?

2018-08-16 Thread Kevin Kenny
On Thu, Aug 16, 2018 at 6:40 PM seirra  wrote:
> oh! before i go to bed just one last one, when correcting some typos or
> wrong use of tagging i've noticed a few locations that used points
> rather than directly applying the feature to the building (as in no
> buildings having features at all as if it was an agreed style)... most
> notably:
> italy north plars
> crescent street montreal
> Czech Technology Park
> Grand Admiral Resort & SPA

The first - I have no idea what sort of an object that is.

The second looks extremely odd - I'd expect something named 'street'
to be represented by one or more ways.

The third and fourth are not necessarily wrong. I'd expect entities
called 'Technology Park' or 'Resort and Spa' to encompass grounds as
well as buildings, with the tags for the whole complex appearing on
the enclosing area.  If a mapper has not determined the area, mapping
a point is acceptable practice as a placeholder.

Hence, for example 'GE Global Research Center' is tagged on an area that
approximates the facilitiy's borders.  The buildings are tagged with
their individual names, but none is tagged with the facility name. The
street address is intentionally attached to the visitor center,
because people needing directions to '1 Research Circle' should be
sent there, rather than to any of the other gates. Before the campus
was mapped in detail, the name was attached to a point feature.

Tagging mailing list

Re: [Tagging] addr:street=* combined with place=square, name=*

2018-08-15 Thread Kevin Kenny
On Wed, Aug 15, 2018 at 7:22 PM Martin Koppenhoefer
> On 16. Aug 2018, at 00:14, Graeme Fitzpatrick  wrote:
>> E.g. km 15,350 is not an addr:housenumber either (used a lot in rural areas 
>> around here)
>> Why wouldn't that be a housenumber?
> because it is an approximate distance, not a number. Places with addresses 
> like this usually don’t have a housenumber.

In many communities in the US, all housenumbers are distance based,
often from a central chaining origin. They are indeed house numbers
when appearing on a postal address: "13430 North Black Canyon Highway,
Phoenix, Arizona" is 13.43 miles (yeah, I know, miles, benighted
Americans) north of Washington Street, or "4750 W. Peoria Avenue" is
4.75 miles west of Central Avenue.  The system goes out a long way,
some of the numbers are in the 40- and 50-thousands.

Tagging mailing list

Re: [Tagging] Tagging a residential bridge building

2018-08-13 Thread Kevin Kenny
On Mon, Aug 13, 2018 at 9:54 PM Kevin Kenny  wrote:
> The negative building levels are correct. The floor numbering attempts
> to be continuous among the connected buildings, and the ones to the
> east were built later without renumbering floors; their levels are
> lettered A-G. E and F connect to floors 2 and 3 respectively.

Sorry, that should be the ones to the WEST were built later, etc.

It struck me as being quite a bit of industrial hubris to continue the
building straight across a ravine. The workers there sometimes joke
that it's our 'horizontal skyscraper'.
It's mosly office space because the infrastructure is limited; all the
toilets, for instance, are in the abutments of the span.

Tagging mailing list

Re: [Tagging] Tagging a residential bridge building

2018-08-13 Thread Kevin Kenny
On Mon, Aug 13, 2018 at 5:10 PM Volker Schmidt  wrote:
> I left out the references to the wiki page: [1], which clearly shows a bridge 
> building, similar in structure to the one I mapped, only much bigger. It 
> straddles a motorway and houses a huge car park. "My" bridge-building is 
> smaller, straddles a park and is inhabited (residential), but the basic 
> concept is the same.
> Both are bridge buildings, not bridges.
> The "tunnel" below is also not correct, because the bridge building is 
> entirely off the ground, like a road bridge.
> [1]

OK, building=bridge it shall be, for my case. I see that the highway
and stream beneath still have to be 'covered' to render properly, and
raising the building to layer>0 doesn't help. The change is made. I
wasn't the one who used 'tunnel' - I agree that it's not right.
'covered=yes' is close enough. If you look straight up from the road,
you will see building and not sky, so the way is indeed covered.

At this point, I'm not going to try to map the short footway that
exists under the building, which runs roughly on the centerline of the
span and in turn crosses the stream on a small bridge. Too much visual
clutter for too little value added.

The negative building levels are correct. The floor numbering attempts
to be continuous among the connected buildings, and the ones to the
east were built later without renumbering floors; their levels are
lettered A-G. E and F connect to floors 2 and 3 respectively. There's
no connection on the other levels. Level A is still far above the
ravine, and the footway has many steps. It's really intended only as a
fire escape, but I used to use it as a shortcut when my laboratory was
in one of the buildings on the riverfront.

Tagging mailing list

Re: [Tagging] Fwd: Missing access value (access=license / authorization?)

2018-08-13 Thread Kevin Kenny
On Mon, Aug 13, 2018 at 6:01 PM Graeme Fitzpatrick

> On 14 August 2018 at 07:24, Martin Koppenhoefer  
> wrote:
>> maybe the way wasn’t impassable before and now it is, I don’t see why it 
>> would be nonsense to state it. Maybe the way is still passable, but you‘ll 
>> die of nuclear radiation? There are infinite possibilities why a way or area 
>> would be made legally inaccessible for everyone, although it doesn’t occur 
>> very often, usually there will be exceptions.
> We actually have this situation at the moment, only not with radiation!
> A dedicated walking track (no vehicles, bikes or horses) round the front of a 
> National Park headland has been closed for several months following a 
> land-slide, & due to the risk of further slips, while they work on 
> stabilising the hill side, so it will be access=no on a path.

OK, we're officially off in the weeds here. (But all apparently
reading from the same page, which is good.) 'No' means 'you cannot',
'private' means 'you may not.'

I'd call the nuclear radiation 'invisblly impassable', but OK, the way
is still visible.  An 'abandoned' lifecycle prefix might be in order
too, since a way in that condition is rather unlikely to be

I'd map the way with the landslide as abandoned:highway=footway or
construction:highway=footway, but I suppose that access=no isn't too
long a stretch. I have a similar situation locally with a
highway=tertiary that was wiped out by a landslide. It's still open to
the handful of people who live along it (who have keys to the gates),
but has a stretch in the middle that's passable only on foot. At the
moment I have it as highway=path, motor_vehicle=no,
abandoned:highway=tertiary, and it still belongs to its route
relation, since it's still signed, "County Road 59." (I should mark it
as highway=unclassified motor_vehicle=private up to the actual
blockage, but it's in the bottom of a deep and narrow canyon with
dense tree cover, and so far I've always lost GPS signal when trying
to map the closed section.)

I once saw a sign reading, "All hope abandon, ye who enter
unauthorized!" access=private access:authority=Dante? The way was not
paved with good intentions. :)

Tagging mailing list

Re: [Tagging] Tagging a residential bridge building

2018-08-13 Thread Kevin Kenny
The one example that I have, I tagged 'building=industrial bridge=yes'
for the part of the building that's above the ground, and then tagged
'covered=yes' on the road and the stream that pass beneath it.

It seems to render well enough, and it makes sense to me. is the bridge.

tunnel=building-passage doesn't make much sense to me for this one -
the bridge is at least sixty metres long and maybe twenty metres off
the floor of the ravine in the centre.

Tagging mailing list

Re: [Tagging] Fwd: Missing access value (access=license / authorization?)

2018-08-13 Thread Kevin Kenny
On Mon, Aug 13, 2018 at 11:07 AM Martin Koppenhoefer
> > On 13. Aug 2018, at 14:35, Paul Allen  wrote:
> >
> > All I was attempting here was to point out that access=no is different from
> > access=private and can have valid uses.   It's not crazy to have both.  It 
> > may be rare to have access=no, but any time
> > you see a sign "No vehicles beyond this point" it applies.
> actually that is vehicle=no
> Still I agree with the rest of what you wrote, there is a distinction of 
> private and no, at least conceptually (not so sure about actual tagging), and 
> no would expectly be much fewer than anything else.

OK, mostly makes sense. 'no' = 'impassable', 'you can't
drive/cycle/ride here because of hazards.'
'private' = 'forbidden', 'you can't drive/cycle/ride here because the
landowner/government doesn't allow it.'

'access=no' standing alone (not 'transport_mode=no', not 'access=no
transport_mode=something') is still pretty nonsensical - what is the
point of mapping a way that's impassable to everything? When is a way
not a way? It does indeed make sense when some transport mode has an
answer other than 'no'.

Tagging mailing list

Re: [Tagging] Fwd: Missing access value (access=license / authorization?)

2018-08-12 Thread Kevin Kenny
On Sun, Aug 12, 2018 at 7:01 PM Paul Allen  wrote:
> However contrived, there will be cases where the bridge itself does not 
> permit access to motor vehicles even though
> the way leading up to it does.  As in "no vehicles beyond this point."
> Now I think about it, I've recently seen a road, which turns into a track, 
> which leads to a slipway.  The track had a sign
> saying no access to vehicles because the track was in a poor state of repair. 
>  Admittedly, it was more to limit the council's
> legal liability than a flat out you-will-be-prosecuted prohibition, but it 
> was part of a public way with no access to
> motor vehicles.  Which I didn't map because the sign said the prohibition was 
> temporary (it will be months before
> I go that way again, if ever).

Yeah, transport_mode=no makes sense. 'access=no' (without a specific
mode) is still pretty weird, as is 'motor_vehicle=no' on any way of a
grade 'unclassified' or higher. I've certainly tagged doubletrack as
'highway=track motor_vehicle=no' (if it's impassible), so I suppose
your distinction makes sense for specific transport modes, and some
combination like 'access=no foot=yes' for a way that can be passed
only afoot would make sense. Hmm, for that matter, I've wondered how
to tag a way across a wetland that's accessible to snowshoe, ski,
snowmobile, but impassible in summer - and conditioning 'access=no
foot=yes @ snow, etc' would be one way to approach that one.

Come to think of it, there's a way near me that is still a numbered
highway, that's impassable to motor vehicles but open as a footway. It
was wiped out in a landslide in 2011, and the county still hasn't
raised the money to rebuild. Both ends are gated. There are a couple
of local residents with keys to the gates, and of course it's open to
emergency access, but it's not *possible* to drive straight
through.(It's a nice hike, with some really interesing geology on that
dormant earthquake fault.) The alternative route is still posted as a
'detour'.. It looks pretty odd when rendered:
 but at this point, it's a 'highway=path' that's part of a
'route=road' with a network and a ref. I tagged it as a path, though,
since the area that crosses the slide is too narrow for mountain bikes
to pass abreast. Maybe I ought to add abandoned:highway=tertiary, but
they still supposedly plan to fix it someday.

I'll use 'highway=track motor_vehicle=no' as well for some of the
older ways around here that are platted as public highways, but were
built before the advent of the automobile and never improved for
automobile traffic. It's still perfectly lawful to walk, or to ride a
horse, mountain bike, or ATV, or snowmobile on them - they're
non-motor-vehicle public roads. (And once in a while the emergency
services will push through them in a Humvee or equivalent.)

I guess where we split is that I tend to tag these odd cases based on
the use that they currently support, and not what they legally are or
may have been. If something is now a path, like the road over the
logging bridge in my earlier photo, that's what I tag it, even though
that bridge was obviously once a track or even an 'unclassified'. The
cases that get dodgy are the ones where the actual status has
deteriorated below the legal status, as in, "this is a public
right-of-way, and it would be legal to drive here, but I'd only
attempt it in a 4WD in dry weather.' That's most likely too subjective
to map.

Tagging mailing list

Re: [Tagging] Fwd: Missing access value (access=license / authorization?)

2018-08-12 Thread Kevin Kenny
On Sun, Aug 12, 2018 at 5:49 PM Paul Allen  wrote:
> Consider a bridge which is structurally strong enough for pedestrians, 
> cyclists and maybe even horses but which would
> collapse if a vehicle drove over it.  The distinction between "private" and 
> "no" for vehicles then becomes clear.  Even the
> owner would not drive a vehicle over it.

Is that not a highway=footway, cycleway, path, bridleway?  In any of
those cases, it would be assumed to be motor_vehicle=no. If it was
once a road bridge, it could also be abandoned:highway=unclassified or
whatever. That's how I mapped - highway=path
foot=yes horse=yes ski=yes bicycle=no snowmobile=no
abandoned:highway=track bridge=yes surface=wood

And by contrast, is
demolished:highway=track while the rubble at the right side of the
image is demolished:man_made=dam highway=path ford=yes et cetera.
Except that I didn't map it, because I didn't attempt the crossing.
I'd already fallen in the [expletive deleted] river once that day, and
that was one time too many.

An unvarnished 'access=no' sounds just plain weird to me - as if
asserting that a way is not a way.

Tagging mailing list

Re: [Tagging] Fwd: Missing access value (access=license / authorization?)

2018-08-12 Thread Kevin Kenny
On Sun, Aug 12, 2018 at 5:37 PM Martin Koppenhoefer
> If there are people who can access, you should prefer “private” over no.
> IMHO we should remove “for the general public” in the above definition. Where 
> did you find this sentence?

This is where I continue to be confused.

Presumably the land owner can always access, which has made the
distinction between 'private' and 'no' unclear to me. By your
definition, the only justification for 'no' would be that a way is
impassable, in which case, why isn't it abandoned:highway=whatever,
rather than highway=whatever access=no?

On the other hand, 'no' meaning 'landowner and designees only', while
'private' means 'some third parties may access, but no permission
routinely granted to the general public' would make eminent sense.

Tagging mailing list

[Tagging] Fwd: Missing access value (access=license / authorization?)

2018-08-12 Thread Kevin Kenny
Oops, posted from wrong return address...
-- Forwarded message -
From: Kevin Kenny 
Date: Sun, Aug 12, 2018 at 4:35 PM
Subject: Re: [Tagging] Missing access value (access=license / authorization?)
To: Tag discussion, strategy and related tools 

On Sun, Aug 12, 2018 at 9:48 AM Szem  wrote:
> I begun to use the "permit" tag, what is the correct tagging for these 
> categories?
> - Roads found in Waterworks area (You could get permit only for biking and 
> walking, no cars except for their own ones)
> access=private, motor_vehicle / vehicle = private ? bicycle=permit, 
> foot=permit, horse=no

Sounds right; no need to tag motor_vehicle separately, since 'access'
covers all transportation modes that aren't called out separately.

> - Roads on the embankments (By any motor vehicle without permission is 
> forbidden, except for their own ones, other access is free)
> access= private, motor_vehicle / vehicle =permit ? foot=yes, horse=yes, 
> bicycle=yes,

If permission is readily obtainable, then 'permit'. If permission
happens on a case-by-case basis, 'private' is probably closer.

> - Roads managed by Hunting Association, wildlife conservation areas (Crossing 
> by any vehicle without permission is forbidden, except for their own ones):
> access= private, motor_vehicle / vehicle = permit, foot=yes, horse=permit, 
> bicycle= permit

Once again, if it's "access granted if you comply with the
formalities", then 'permit', otherwise 'private'.  The Hunting
Association one sounds as if it restricts access to its own members?
In that case, it's definitely "private."

Tagging mailing list

Re: [Tagging] Missing access value (access=license / authorization?)

2018-08-08 Thread Kevin Kenny
On Tue, Aug 7, 2018 at 10:11 PM Graeme Fitzpatrick
> Yep, Kevin's proposal solves a lot of problems.
> Let's try to push it along & get it approved.

I haven't forgotten. I'm just going through a crunch time at work, and
haven't had time to draft the thing formally.

Tagging mailing list

Re: [Tagging] Missing access value (access=license / authorization?)

2018-08-02 Thread Kevin Kenny
Is there a documented process for putting a proposal? I'm certainly willing
to draft the text, although I'm not going to be able to do it before the
weekend. Can someone else run the proposal process or at least guide me
through it?

On Thu, Aug 2, 2018, 12:55 PM Szem  wrote:

> A couple of us have said their opinion.
> It seems to me nobody have said the access=permit tag is useless.
> And now, what is the next step? Worldwide the 97% of editors have not read
> this mailing list. Without written a short explanation in the wiki only a
> few editor will use it, or they will use a lot of other form.
> (There would be no greater agreement if we would analyze e.g. 
> access=permessive
> tag…)
>  Szem
> ___
> Tagging mailing list
Tagging mailing list

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

2018-07-30 Thread Kevin Kenny
On Mon, Jul 30, 2018 at 11:39 AM Martin Koppenhoefer
> I did not check any numbers, but I would also expect a lot of data not 
> following this definition.
[of the ele=* tag meaining EGM96]

Uhm, yeah.  I've been using NAVD88 as orthometric datum. I have the
tables loaded in my
GPS app, and it's what surveyors use locally.  But the difference
between that and EGD96
is far too small for my equipment to measure - I don't have a
survey-grade GPS, or the
patience for the integration time that using one requires.

Entering ellipsoidal height rather than orthometric elevation, though,
is Just Plain Wrong -
and I bet we have a lot of data entered that way that are off by tens of metres.

I further bet that two-thirds of the people reading this thread have
Absolutely No Idea
what we're talking about. (That isn't really a severe criticism. It's
more an indictment
of the sorry state of consumer-grade GPS that ordinary mappers would
be forced to
learn that much geodesy to get it right.)

Tagging mailing list

Re: [Tagging] Missing access value (access=license / authorization?)

2018-07-30 Thread Kevin Kenny
On Mon, Jul 30, 2018 at 5:56 AM Volker Schmidt  wrote:
> I would make the distinction bub from a map-data end-user's point of view: 
> can I walk/drive up to the place and obtain a permit on the fly, with or 
> without paying a "fee". The on-the-fly payment may include payment of 
> membership of some kind on first entry, or similar arrangements. If access 
> requires prior membership in a club or an association, I would suggest to use 
> access=members. Admittedly there is a soft border with "customers", for 
> example in case of access to the car park of shops that requires membership 
> (e.g. REI in the US).

You're right, that's certainly a consideration. In my mind, it's at
the next level after 'is permission routinely offered to the general
public, or do I have to have a reason for being there?'

One use case for wanting to know that:  Let's say that I want to plan
a trip to climb North Dome, Balsam Mountain and Mount Sherrill - which
cluster around None of
these has an established trail. I can access North Dome from the north
by one of several narrow strips of foot=yes land that border County
Road #6. I cannot access from the south over the abandoned logging
road, because Camp Timber Lake is access=members and does NOT welcome
visitors. I can access Balsam Mountain from CR6 to the north as long
as I've brought my (free of cost) permission card, because the general
public routinely has access to In fact, the city
recently changed that unit from foot=permit to foot=yes, so I don't
even need to remember the card.

For what it's worth, on the actual trip, I started from, followed the survey line
north of North Dome until it intersected the northern spur of the
mountain, and got to the summit from there, and eventually emerged at That way is mismapped
(thanks, TIGER!), but my GPS was wonky just then, and I haven't been
back down that way since, so I left it alone. It's a service way that
goes to a shaft associated with the water tunnel. There's parking for
climbers and hunters there.

I'm a long way from mapping 'access=members' recreational areas.  I
have my hands full with public ones!

By the way, REI doesn't require a membership to enter or to shop (and
incidentally sells the membership in-store). Most shoppers there are
members, because there are discounts, dividends, and extended
warranties on purchases that they find to be worth the small fee for
becoming a member. But there are stores with the model that you
imagine - usually they're wholesalers that aren't set up to collect
general sales tax, so require their customers to have a membership
(with a business licence and reseller number on file). Some of these
have branched out into direct-to-consumer sales but continue a
membership requirement.

Tagging mailing list

Re: [Tagging] Missing access value (access=license / authorization?)

2018-07-27 Thread Kevin Kenny
On Fri, Jul 27, 2018 at 11:54 AM marc marc  wrote:
> a good idea would be to explain with a (as easy as possible) example
> why access=customers or private does not fit for your need.
> If it was what you did in your previous email, sorry but I didn't
> understand it, because your examples are too general, without
> explanation about existing tag problems

(Side note: I favour 'access=permit' over 'access=licence' because
it's spelt the same way on both sides of the Atlantic. Choosing a tag
that's spelt differently in US and UK English simply invites

Here's an attempt at an explanation:

In the area that I'm mapping, there are rural regions - even with the
same land management - that have different regulatory regimes - and I
wish to render them differently.

They fall into major categories.  I'll also include specific examples
from the New York City water supply lands, because that specific land
owner has (or has had) examples in all the categories.

[1] 'access=private'.  These are private lands, or government-owned
lands for which public access is not routinely granted. They are
usually posted 'NO TRESPASSING' or similar verbiage - but would also
comprise farmers' fields and the curtilage of private houses. For
these, unless I have a relationship with the landowner, I have no
reason to expect access, and it would be regarded socially as being
quite strange to request it without a compelling reason.  On a hiking
map, I'd show these as 'out of bounds - off limits'.

The New York City water supply bureau owns large parcels of land in
this category - marked with uniform yellow NO TRESPASSING signs. that
look like
. I cannot show an OSM example because I haven't mapped them in OSM. I
don't map that sort of cadastre; instead, for lands, I consider
'access=private' to be the default.

Summary: "Ordinarily, no access to the general public"

[2] 'access=customers'. There are a number of clubs, resorts, ski
areas, and similar facilities that sell access (often labeled
something like a 'grounds membership' - offering the right to cross
the lands but none of the other club services). There is a reason that
I might be authorized as a member of the general public. (Of course,
'customers' may also include guests of members, conference attendees
at resorts, and similar prople.) Some government-owned lands fall
under this category - for instance, there are government
watershed-protection lands that ordinarily offer public access only in
hunting season to hunters who've paid for the privilege.

The New York City lands under this scheme are marked with
special-purpose signs like .
These signs differ from area to area, since so do the ways of
obtaining the privilege to use the land.  I do see this as an actual
business-customer relationship (with the government as the business).
One such area is It's not
tagged 'access=customers' at present, but I'd have no objection to
making the change.

Summary: "Access only to transact with the public-facing business that
occupies the land"

[3] 'access=permissive'. This more often applies to ways than lands,
but it there's no reason it couldn't apply to either.  Often, a
landowner will retain control of access but offers the general public
revocable rights to cross the land, usually in a specific corridor.
There will ordinarily be the indicia of a hiking trail, and frequently
there will be NO TRESPASSING signs on either side of the trail. Often,
there will be standing rules; for instance, one trail that I access
has a standing closure from October 15-December 31 of each year, plus
occasional closures when members of the family that owns the land are
hosting large gatherings.

There are several trails that cross otherwise-posted New York City
watershed lands. One example is,
which is on such lands between the end of the pavement on Jessup Road
until it starts following the boundary of the Mount Tobias wild
forest.  In the field, there are NO TRESPASSING signs on both sides of
the trail corridor from Jessup Road to the property corner, and then
NO TRESPASSING signs on the northeast side up to the junction with the
trails to Warner Creek and to Phoenicia. I've also been in there and
found that permission had been revoked temporarily, with signage that
looked like
(The workers were friendly, and conducted my party through the
closure.) I concede that the 'highway=footway' there may need
'foot=permissive', but I'm not going to trouble to retag unless I
happen to find out whether a permanent easement exists for the trail.
(If there's a deeded easement, then of course it's 'access=yes' and
the closure was akin to closing a road for a brief construction

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

2018-07-27 Thread Kevin Kenny
I'm all for SI units for things like voltages and elevations. I'm
perfectly fine with tagging the elevation of Slide Mountain as 1274
metres and letting a US data consumer convert that to 4180 feet.

Regulatory things like maxspeed=* should have the unit in the tag, and
they should be in the same units that the signs are in. A sign reading
'Speed limit 25 mph' means 25 mph, and entering 40.2336 km/h loses the
information that the regulatory signs are in US customary units.

Data consumers have to deal with that stuff now - and it's not that
difficult,. I've done software that consumes OSM data, and unit
conversion was a much lesser headache than a lot of other tagging
On Fri, Jul 27, 2018 at 1:31 PM marc marc  wrote:
> Le 27. 07. 18 à 18:51, Richard Welty a écrit :
> > but practically it's probably not a good idea in mapping, where i think
> > we should be using local units in an unambiguous manner.
> nothing prevent a editor nor a site to show "volt" next to the textbox
> for voltage value nor to show "km/h or mph" next to the textbox for
> maxspeed depending of the location.
> it only needed to have something to tell data user if a tag have only
> one unit or if the unit varies according to location (in this case, we
> need again a schema to store default value (in this case unit) somewhere
> with a link with osm location).
> Le 27. 07. 18 à 18:52, Philip Barnes a écrit :
>  > On 27/07/2018 16:20, marc marc wrote:
>  >> I agree maybe with the exeption of case like maxspeed
>  > And maxheight and maxwidth.
> I agree that it'll be easy to not include those tag, at least to start.
> it's why voltage is a very good usecase to start with it :)
> >
> > On 7/27/18 11:20 AM, marc marc wrote:
> >> I agree maybe with the exeption of case like maxspeed
> >>
> >> François voltage is a good usecase to open an issue to the whised app.
> >>
> >> Le 27. 07. 18 à 14:19, Andrew Hain a écrit :
> >>> My own preference is to have no (zero) units in the database, decimals
> >>> where wanted (maxwidth=2.2) and unit management support in editors.
> >>>
> >>> --
> >>> Andrew
> >>> 
> >>> *From:* Warin <>
> >>> *Sent:* 27 July 2018 12:27:04
> >>> *To:*
> >>> *Subject:* Re: [Tagging] Let's get (quite) rid of units and their
> >>> multiples in OSM values
> >>> On 27/07/18 21:11, Martin Koppenhoefer wrote:
>  sent from a phone
> > On 26. Jul 2018, at 21:26, François Lacombe  
> > wrote:
> >
> > I don't want to break things but only improve them, all the best
>  one issue with using only one unit for a tag is that they can’t always 
>  be transformed without rounding. E.g. maxspeed=55mph cannot be converted 
>  to kph without losing information
>  Also, shorter notations are better readable, hence reduce the likeliness 
>  of errors not noted.
>  On the other hand, I agree in the example of voltage it would make it 
>  easier for queries to use the same unit. (you still can make queries, 
>  but they are more complicated if you have to take units into account)
> >>> Unfortunately not everyone uses the same units... heights are in meters,
> >>> feet .. depending on where you come from or what activity you follow.
> >>>
> >>> Voltages are in volts so the same units... but multiplies are common for
> >>> high voltages .. no one uses 33000 volts .. they all use 33 kv.
> >>> If you stipulate that all voltages have to be in kv then 115 v becomes
> >>> 0.115 kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
> >>> that is not how people talk about these things.
> >>>
> >>>
> >>>
> >>> ___
> >>> Tagging mailing list
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> Tagging mailing list
> >>>
> >>>
> >>>
> >>
> >> ___
> >> Tagging mailing list
> >>
> >>
> >
> >
> ___
> Tagging mailing list

Tagging mailing list

Re: [Tagging] Missing access value (access=license / authorization?)

2018-07-26 Thread Kevin Kenny
On Thu, Jul 26, 2018 at 3:40 PM marc marc  wrote:
> Le 26. 07. 18 à 19:39, Szem a écrit :
> did you read the previous (a few month ago) thread about this kind of
> issue ?
> imho *=licence is included in the current meaning of *=customers

The only outcome of that thread - and several threads on the same
subject that preceded it - was that there was no consensus. I
understand that you are entirely convinced that your personal view is
the only correct one. Several others on the thread were convinced,
equally unalterably, that this regime is a special case of
'access=private' or 'access=no', and a few that it was not very far
removed from 'access=yes' or 'access=permissive'.

I'm equally convinced that 'access=permit' really is a thing unto
itself, and that attempting to force-fit it into one of the other
categories is misguided. (In fact, that force-fitting occasionally
comes across as being close to an admonition, "The data model is fine.
Fix your country!")

Several countries (US, CA, AU, apparently HU) have schemes where
government land is accessed by permit. The permits are often free or
granted for only a nominal fee, and usually the only condition is that
you have to identify yourself and agree to follow the specific
regulations pertaining to the area or way in question. The permits are
often more about getting a signed agreement to follow the rules than
they are about collecting fees or restricting numbers.

An example is that New York City's Bureau of Water Supply has all of
the following cases - and some of us want to distinguish among them on
the map!

access=yes -

access=private(or no) -

access=permissive - I don't have a good example of signage, but there
are blazed trails that cross otherwise 'access=no' land and are signed
accordingly. Trailhead signs look like,
the red markers regularly waymark the trail, but the 'NO TRESPASSING'
signs may be posted on both sides of the trail corridor.

access=permissive (but permission temporarily revoked) -
(I don't try to keep up with these projects on the map. They're too

access=permit - (One
occasionally sees the obsolete

access=customers - (You
pay for the deer tag and are allowed in in the hunting season only for
the purpose of hunting.)

From this list, perhaps people can see why I think that 'permit' is a
separate thing from the others. These areas aren't signed alike. They
truly do - to my thinking - have access restrictions that are
different in kind, not just in degree.

I've heard from some that the scheme I describe doesn't make any
sense. Nevertheless, it's there. It's field-observable (read the text
on the signs). I wish to produce maps that render all five of these
cases (public, private, permissive, customers, permit) differently.
(In previous discussions, I have been accused that such a desire is
'tagging for the renderer.' Nevertheless, it is an obvious logical
impossibility to render differently areas that are tagged alike.) I
wish to use these maps for planning purposes - to know, for instance,
whether I need to bring my New York City access card or parking tag on
a particular outing.

I do not see a consensus that 'access=permit' is a bad idea. Different
users repeatedly request it, and when I was unwise enough to bring it
up on my own accord, several other users agreed with me. Rather I see
that there is a failed consensus that it is a good idea, and no single
alternative has been presented for which there is a stronger
consensus. One user even asserted that the only way to map such an
area would be to create nodes for the individual signs!

I will confess that I've been remiss about wikifying my thoughts on
the matter, despite having entered quite a few 'access=permit' areas.
Part of the reason is that I'm virtually certain that doing so would
only be firing the first shot in an edit war. That's how badly mappers
disagree on this point.

Tagging mailing list

Re: [Tagging] Lake or Pond

2018-07-20 Thread Kevin Kenny
>> Does light reach the bottom of the deepest point of the water body?
>> Does the water body only get small waves (i.e., smaller than 1ft/30cm in 
>> height)?
>> Is the water body relatively uniform in temperature?
>> If these questions can be answered with a “yes,” the water body is likely a 
>> pond and not a lake.1
>> Other national technical typologies do include a lower area requirement 
>> ranging from .5 hectares ( 'two NFL football fields' for USA residents ) to 
>> 2 hectares, and other various factors like inflow/outflow, relation to the 
>> water table, sediment suspension, etc.

I tag it all 'natural=water' and let other people worry about the
difference between a man-made pond and a reservoir and a flooded
basin. (I do use 'landuse=basin' for the ones that are only
ephemerally flooded.)

Otherwise, I'd go crazy with trying to label things in the complex
glaciokarst topography around here. Examples:

A 'lake' that is actually a permanently flooded ponor, with its outlet
an intermittent stream that flows in the wet season, and is rejoined
below the escarpment with several streams flowing out of cave
entrances, one of which is suspected to be the main drainage of the

A tarn or two.

A flooded kettlehole or two.

Large sporadic water bodies - some running to hundreds of hectares and
big enough to land float planes - that will be wet meadows in years
that the beavers aren't in residence. These are definitely impounded
reservoirs - but the impoundment isn't anthropogenic!

Reservoirs formed by anthropogenic raising of the water level of existing lakes.

And that's before we even get into trying to distinguish the things by
pH. (Acid bogs vs neutral-to-alkaline fens, etc.)

At least few people here are trying to distinguish based on area
alone. That's very good. If I want "waterbodies in excess of 10,000
m²" or whatever, I can compute areas from the geometries, thank you
very much. No reason to have separate tagging for just that!

Tagging mailing list

  1   2   3   >