[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)
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
[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)
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
Re: [Talk-us] For comment: import of amenity=bicycle_repair_stations
On Wed, Mar 25, 2015 at 2:37 PM, Mike N nice...@att.net wrote: I happened to be near one of these today, and I had to move it about 8 meters. REVERT! (not really, just kidding) ... My only comment about this import would be that I don't think that it is useful to accompany an import with mass notes or FIXMEs. If someone notices that the position is off, they'll correct it or leave a note. In this case it wasn't too serious because the number of data points is low, but would be more of a problem with a larger dataset. From what I've seen the notes have worked really well: better than I could have hoped. Every few days someone finds one of those notes, hunts down the tool stand, and closes the note. A number of note closers have been beginning mappers as well: perhaps these notes represent a mapping task that's both in their area and accessible at their level of mapping comfort. If the notes have brought a modest number of mappers out of the glow of their computer screens, and out into the community, that's great. -- Most of the nodes were pretty close: but the occasional one has moved pretty far (at least 40 meters). Every station searched for on the ground has been found, with one exception. That station was subsequently deleted from both OSM and the vendor database at Dero corporation. The on the ground mapper took multiple visits to the site, after the company provided more details. But it's just not there. -- Perhaps the notes that remain after a set period (maybe a year) should be bulk deleted. The notes in the USA are getting resolved at a steady pace. The notes in the UK (which were imported without nodes) have not attracted much interest. I am concerned that some mappers will fix a tool stand location, but never notice the corresponding note. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] New features in iD - looking for feedback and beta testers..
Hi Everyone… It’s been a busy few months for the iD team, and we have a handful of new features that will be launching soon. We’d love to get some mappers to beta test and provide feedback! These features are available now by using the latest development branch of iD hosted at http://openstreetmap.us/iD/master/ http://openstreetmap.us/iD/master/ Please try them out and report any issues or questions on our Github issue tracker: https://github.com/openstreetmap/iD/issues https://github.com/openstreetmap/iD/issues - Copy and Paste selected features with ⌘-C and ⌘-V https://github.com/openstreetmap/iD/pull/2498 https://github.com/openstreetmap/iD/pull/2498 - Conflict Resolution iD will now check if any of your modifications conflict with edits made by other users, and will present you with a UI to see the difference and choose how to resolve the conflict. https://github.com/openstreetmap/iD/pull/2489 https://github.com/openstreetmap/iD/pull/2489 - Smarter Way Movement When moving a connected way, iD will now slide the moving way along the non-moving way, rather than “zorroing” the connection point. https://github.com/openstreetmap/iD/pull/2516 https://github.com/openstreetmap/iD/pull/2516 - Don’t delete ways that are part of a route/boundary Relation This will prevent a bunch of breaking edits to relations - Thanks RichardF! https://github.com/openstreetmap/iD/pull/2526 https://github.com/openstreetmap/iD/pull/2526 - Map-In-Map You can now bring up a locator mini-map with the ‘/‘ key. By default it displays the current area but zoomed out by -6. Zoom and pan the mini-map to quickly find and move to different locations. https://github.com/openstreetmap/iD/pull/2554 https://github.com/openstreetmap/iD/pull/2554 Thanks! Bryan___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
