[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Minh Nguyen]

On 2015-03-25 08:12, Martijn van Exel wrote:

On Wed, Mar 25, 2015 at 3:00 AM, Minh Nguyen wrote:

On 2015-03-24 13:57, Martijn van Exel wrote:

More importantly though, there is an authoritative source for
official administrative boundaries that can be easily accessed by
anyone: TIGER[1]


You mean the way TIGER is an authoritative source for road
centerlines? TIGER's boundaries vary in quality just as its roads
and railroads do. I've taken quite a few imported municipal
boundaries, lined them up with road easements or hedges between
farms _when that is obviously the intent_, and deleted extra nodes.
These borders become far more accurate and precise in OSM than in
commercial maps, which regurgitate TIGER boundaries verbatim.


The most authoritative source for most U.S. land borders, going all
the way down to the parcel level, is a legal prose definition in
conjunction with any number of monuments on the ground. Both metes
and bounds and the Public Land Survey System rely on monumentation.
A monument may be a major road or as obscure as a small iron pin
embedded in that road, but even that pin is verifiable if not
particularly armchair-mappable.


If you're lucky, you can find an Ohio city limit's legal definition
in county commissioners' minutes when an annexation is proposed. The
most authoritative data representation is the county GIS database,
which anyone can easily access -- for a fee. After paying the county
for that database, you might well forget about OSM, because it's
also the authoritative source for road centerlines and names.


That is actually not what I meant, but I could have been more precise. I
guess this turns into a discussion of what 'authoritative' actually
means. This is different things to different people. As OSM becomes
better, increasingly folks will start looking at us for
authoritativeness, which would make sense because everything is
(supposed to be) verified on the ground. Because administrative
boundaries have legal implications, the authoritative source will need
to be someplace outside of OSM. It may actually hurt OSM down the line
if we include information that suggests authoritativeness we cannot
provide.


OK, thanks for clarifying. One risky use of administrative boundary data 
at the local level would be for tax purposes. Obviously we don't want 
people relying on OSM to decide whom to pay taxes to. That's why we have 
a disclaimer. [1] It should get more prominence. Wikipedia's legal and 
medical disclaimers are two hops away from every article, but ours is 
two hops from the wiki's main page only. At least consumer-focused 
redistributors of OSM data tend to have more accessible disclaimers.


[1] http://wiki.osm.org/wiki/Disclaimer


Sure, but vernacular and official neighborhood objects would then need
to be represented differently so folks can tell them apart and know what
they are dealing with.


I agree entirely, and I think OSM is already set up for these 
distinctions. If you see a boundary=administrative admin_level=10 
relation on the map, you'd expect it to be an official (aka 
administrative) boundary, not a vernacular one. If you see a 
place=neighborhood POI with the name tag, you'd expect both definitions 
to be roughly equivalent. A purely vernacular neighborhood would be a 
POI probably tagged with loc_name instead of name.


--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)

[Minh Nguyen]

On 2015-03-25 09:54, Bryce Nesbitt wrote:

There are many defacto boundaries created by roads, hedges, powerlines,
ridges or bodies of water.

I argue the most appropriate boundary in OSM is indeed the defacto
boundary.  If people are using, paving, weeding
and farming the boundary, that's the one we can map.

The legal boundary is not something OSM can adjudicate.  Finding that
boundary is a complex process involving survey points, land
descriptions, and often handwritten records stored in dark basements.
It also hardy ever matters, at least to a mapper or map reader.


That may be true when it comes to private property, but the de jure 
boundary of a given village, county, etc. matters to many members of the 
general public, all of whom could wind up reading our map. To the extent 
that a given place has a de facto boundary -- which I take to mean a 
boundary not *administered* by a government -- we shouldn't map it as an 
*administrative* boundary, and we should avoid mapping overly subjective 
data in fine detail anyways.


I would imagine that administrative boundaries like city limits are a 
matter of public record. Granted, the public record isn't necessarily 
free or online, and the city may well store it in a dark basement. But 
where we can ascertain the legal definition of a city limit while 
respecting our copyright policies, we provide a valuable service by 
turning that prose into free geodata correlated with other features like 
roads. TIGER gets us most of the way there for city limits but not for a 
major city's political subdivisions.


--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Elevation in local units

[Bryce Nesbitt]

On Thu, Mar 26, 2015 at 2:44 PM, Lars Ahlzen  wrote:
>
> By the way, I thought that the wiki page for ele *used* to say that other
> units than m were acceptable (if explicitly specified) but I may be
> confusing it with something else, like width?

FYI: There's a wiki template that could be extended to give consistency to
unit rules, wiki wide.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Elevation in local units

[Lars Ahlzen]

On 03/25/2015 01:43 AM, Bryce Nesbitt wrote:


  * I feel that osm convention should encourage all mappers to specify
units (e.g. 22 m).
  * That whitespace should be allowed (e.g. 22m, 22 m, or even 22 meters).
  * And that local units should be encouraged (e.g. 22 feet, or 22' 0").

The wiki templates, if spruced up, could define the rules uniformly 
for all keys that take a measurement unit

(e.g. height, width, ele, max_height, etc).
--
Parsers are cheap.  Any parser worth using can convert 22m, 22 m, 22 
feet or a variety of reasonable variants.

Humans are messy.  Forcing them into boxes generally goes badly.


+1

As much as wish meters were used everywhere, I'd rather make it easier 
for contributors by letting them use whatever make sense to them, and 
worry about unit conversion later. Especially in this case, where 
mechanical conversion is so easy. If the elevation was surveyed in feet, 
entering it in m will almost always result in loss of precision.


For my own maps, such as [1], I use a simple osm2pgsql lua script [2] 
that does various preprocessing, including converting all ele and width 
tags to feet. It's fairly liberal in the formats it accepts for values.


By the way, I thought that the wiki page for ele *used* to say that 
other units than m were acceptable (if explicitly specified) but I may 
be confusing it with something else, like width?


[1] http://toposm.ahlzen.com/hikemap.html
[2] https://github.com/Ahlzen/Hikemap/blob/master/hikemap_tagtransform.lua

- Lars


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] user damages administrative boundaries around Rapid City

[Minh Nguyen]

arch_arch@...  writes:

> I've detected a user who damages administrative boundaries around Rapid
City. I've tried to contact the
> user but I got no reaction. I've told the mapper that iD editor is
inappropriate, as it has no built in
> validator but he didn't stop the edits.
> 
> I want to ask someone from the US to take care of the case and to involve
the Data Working Group if necessary.
> 
> This boundary got deleted: http://www.openstreetmap.org/relation/194816
> invalid geometry: http://www.openstreetmap.org/relation/195005
> invalid geometry: http://www.openstreetmap.org/relation/194808
> deleted relation: http://www.openstreetmap.org/relation/194807

It's clear that the user simply meant to remove the CDP boundaries (194816
and 194807), an action that many of us on this list (but maybe not all)
would approve of. [1] Unfortunately, the user removed the CDP boundaries by
deleting all the ways that belong to the CDP's relation, roping in members
of neighboring non-CDP boundary relations.

The good news is that Richard Fairhurst patched iD to prevent errors like
this in the future. [2] The bad news is that the fix didn't make it into
1.7.0, the version currently on osm.org. So in the meantime we'll have to
rely on user education.

Echoing Greg's comments, even experienced mappers sometimes hop into iD or
Potlatch to make quick edits. These editors may not be as mature as JOSM
when it comes to relations, but it isn't necessary to dismiss them out of
hand. When it comes to educating new mappers about data entry errors, I've
found them to be more receptive to messages like "please be careful; here's
what to watch out for".

Thanks for bringing up this topic. It's an opportunity to remind mappers new
and old to review their changesets before saving. iD's save panel lists
changes along with validator warnings for some common errors. [3] If iD's
validator is missing a check you consider useful, I'm sure the developers
would appreciate a bug report. [4]

[1] For example, see this thread:

[2] https://github.com/openstreetmap/iD/pull/2526
[3] https://github.com/openstreetmap/iD/blob/master/js/id/validate.js
[4] https://github.com/openstreetmap/iD/issues


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] user damages administrative boundaries around Rapid City

[Serge Wroclawski]

On Thu, Mar 26, 2015 at 4:21 AM, Greg Morgan  wrote:

> The last thing that I would want to do is involve the Data
> Working Group.

I'm sending this mail as a DWG member- but I'm only speaking for
myself, and not on behalf of the DWG.


I don't think most people realize that the DWG will often get
complaints, and usually don't take administrative action. It's quite
frequent that we get a complaint, and our resolution to the matter is
to mediate a disagreement, or focus on education of one or more
mappers.

Most of the time a resolution can be found without needing to take any
official DWG actions. The DWG member's role in those situations is as
a third party who can come in, hear everyone's side, and try to find a
resolution that works for all parties.

In fact, I think that one thing the DWG members would like is if more
mappers took time to try to find another solution before contacting
the DWG. Many times we'll get a complaint from one user about another
mapper's mapping practices and the person complaining hasn't used
changeset discussions to, or in some cases even having send someone an
in-system message. In other words, the person being complained about
may not even know that there's someone whose upset.

Reaching out to your fellow mapper should your first step in any
conflict resolution. If that doesn't work, the DWG is there to help,
and you should feel free to contact them.

The DWG email address is d...@osmfoundation.org

- Serge

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] user damages administrative boundaries around Rapid City

[Greg Morgan]

On Wed, Mar 25, 2015 at 3:13 PM, arch_a...@t-online.de <
arch_a...@t-online.de> wrote:

> Hello,
>
> I've detected a user who damages administrative boundaries around Rapid
> City. I've tried to contact the user but I got no reaction. I've told the
> mapper that iD editor is inappropriate, as it has no built in validator but
> he didn't stop the edits.
>
> I want to ask someone from the US to take care of the case and to involve
> the Data Working Group if necessary.




> There may be also other damaged objects.
>

http://hdyc.neis-one.org/?gm360st

Pascal says: 302 project days; 117 mapping days; ... the last modifier of
28k nodes using Potlach and iD using 3,936 change sets.  In my book,
gm360st is a valuable young mapping resource more so than a couple of
broken polygons.  The last thing that I would want to do is involve the
Data Working Group.  The bar has been purposely lowered to include and
attract new mappers via the iD editor.  iD is gm360st's editor of choice.
There are a number of tools to correct these issues.  At this point in time
I wouldn't even follow the mapper and correct the problems.

The real question is how do you gently grow a young mapper like this
without alienating the valuable resource?

Regards,
Greg
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us