Re: [Talk-us] Retagging hamlets in the US
On Wed, Mar 25, 2015 at 7:33 PM, Alex Barth wrote: > Note we're only talking about `place=hamlet` in urban areas. I wasn't 100 > % clear whether your post referred to `place=hamlet` nodes in urban areas > or in general. Sorry - I missed the Urban part. The 55 are definitely not urban. However, my concerns about neighborhood boundaries are all in urban areas. -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Retagging hamlets in the US
On Thu, Mar 19, 2015 at 6:12 PM, Clifford Snow wrote: > I apologize for coming in so late on this thread. Looking at my small > county, we have 55 place=hamlet according to an overpass query. Note we're only talking about `place=hamlet` in urban areas. I wasn't 100 % clear whether your post referred to `place=hamlet` nodes in urban areas or in general. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] user damages administrative boundaries around Rapid City
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. 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 There may be also other damaged objects. Greetings from Germany, Arch Profitieren Sie von der sicheren E-Mail-Übertragung Ihrer Daten mit einer kostenlosen E-Mail-Adresse der Telekom. www.t-online.de/email-kostenlos ___ 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
I happened to be near one of these today, and I had to move it about 8 meters. REVERT! (not really, just kidding) I think this was a useful dataset for import. And if there were some variations on the actual position, I don't see how this is any different from typical mapping errors, such as the POI that someone had placed on the wrong building, resulting in a 30 meter error. 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. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On Wed, Mar 25, 2015 at 2:00 AM, Minh Nguyen wrote: > 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. Ah, another sticky wicket. 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. Note that in the USA boundaries are determined by reference to written deeds, and subject to challenge in court. Various non-registered rights, including right of passage, may exist. It's a huge mess. In Australia, as I understand, land ownership is a matter of public record, and all ownership changes must be registered. The government records are, by definition, correct. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)
On Wed, Mar 25, 2015 at 3:00 AM, Minh Nguyen wrote: > On 2015-03-24 13:57, Martijn van Exel wrote: > >> I have long been on the fence about boundaries in OSM, and while I don't >> feel as strongly about it any longer, it still feels wrong to make this >> sweeping exception to one of the fundamental conventions of OSM mapping: >> verifiability. For many types of land use, anyone would be able to >> verify boundaries on the ground: a forest, a corn field, even a retail >> zone in most cases. But administrative boundaries can only be observed >> in a limited number of places: wherever there is a sign or a physical >> boundary in place, and rare other cases. >> > > Admittedly, a given border can be observable along one segment but not > another. However, we tend to map the entire border for the sake of > completeness, convention, and technical reasons -- closed areas are much > more useful than stray lines. OSM has long gone to extremes on this point, > going so far as to enclose all continents and island nations in maritime > borders. > > Hopefully you had the chance to read my case study on Illinois, Indiana, > Ohio, Kentucky, and West Virginia earlier in this thread. [1] You can > observe much of the Ohio-Indiana state line quite precisely, both on the > ground via welcome signs and mile markers and from the air via changes in > land use and pavement quality. But you cannot observe the Ohio-Kentucky > state line except by visiting a library, and the Ohio-Ontario border is an > imaginary line. Which of the five options would you have chosen for Ohio? > > [1] https://lists.openstreetmap.org/pipermail/talk-us/2015- > March/014485.html I have, and my (admittedly much more limited) experience in Utah does not suggest I would be able to determine a reliable state boundary from information on the ground. County lines even much less so. > > > 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. > > > All of this has little to do with neighborhoods, which are mostly (?) >> vernacular in naming and delineation, and even when there are official >> neighborhood designations, in my own experience they do not always match >> the vernacular names. I support point mapping of vernacular >> neighborhoods. If you really want to have shapes for vernacular >> neighborhoods, you can look at the now-ancient-but-still-cool flickr >> Alpha Shapes[2], last updated in 2011 but still available for >> download[3]. But please don't upload 'em to OSM :) >> > > As a political boundary (in the political map sense), an official > neighborhood designation can be distinct from the neighborhood with a > vernacular name, but that's an argument to map both rather than favoring > one over the other. They coexist and might share a name but aren't > necessarily the same thing. People should be able to get the concrete, > objective boundary of an official neighborhood from OSM and an amorphous, > subjective boundary of an informal neighborhood from A
Re: [Talk-us] USA Rail: Calling all OSM railfans! (especially in California)
Hello Peter:
The California/Rail wiki page you describe documents a couple of
different ways we tag rail. OpenRailwayMap (ORM) documents a three
tier (route=tracks, route=railway, route=train) method used in parts
of Germany. As that page (as well as the USA Rail WikiProject)
explain(s), because of the way TIGER entered rail in the USA, (and
the way we structure and name rail) we often use just two of these,
skipping route=tracks relations and "jumping" right to putting "named
rail" into relations of route=railway: rail "infrastructure." You
might say that two ORM/German-style "lower and middle level"
relations have been merged into a single "middle level" relation here
in the USA. There are also ("higher level," and the whole OSM world
agrees) passenger rail relations: route=train (or route=light_rail,
route=subway, route=tram...effectively at the same logical "level" as
route=train). That's OSM rail "structure" in a nutshell.
In Oregon, there are the Brooklyn Subdivision
(http://www.osm.org/relation/2203588), the Fallbridge Subdivision
(http://www.osm.org/relation/1443651)... these are (correctly) the
middle-level infrastructure relations tagged route=railway. There
are also (predictably, also, the higher-level) route=train passenger
rail relations like Amtrak Cascades
(http://www.osm.org/relation/71428) which are often made up of a
group of Subdivisions (route=railway relations) like Brooklyn and
parts of Fallbridge.
THIS is what Paul was typing about in those Notes. Specifically, a
(higher-level/passenger) route=train relation should not have as its
name=* tag the name of the system (like MAX, BART, Metro or Amtrak),
it should be the name of the passenger line (Green Line, Downtown to
University...). And, the "underlying" (lower-level infrastructure)
route=railway relation should be correctly "named" as the rail
company (or public works department, transit district...) names it:
often something like XYZ Subdivision or ABC Industrial Line.
OSM's Transport Layer is handy to display (rather raw) railway=* and
(at closer zoom levels) route=bus.
ORM is handy to display rail infrastructure (with Infrastructure
radio button selected), especially usage=* tags.
OpenPublicTransportMap (http://openptmap.org) is handy to display
passenger rail relations.
The USA is largely under construction for all of these, but we've
come a long way.
It's all in those wikis. Makes sense?
Regards,
SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
On 3/25/2015 1:43 AM, Bryce Nesbitt wrote: 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. For a bit of history - having speed limits allow a fixed format of [Number][Space]mph made great sense for the same reasons. There was some pushback from data consumers and renderers. At least one person didn't like this at all. And nearly every tool which would render speed on reference maps or devices did not function for road maxspeeds specified in this manner until one or several revisions later - up to a delay of several years. Parsers make this task simple, but in practice OSM data is processed by loading into a database and querying numeric fields as numbers. That process can be modified, but again it will take some time. My input is to allow mappers to work with local units, but modify editors to add the feature of specifying in feet. The editor would continue to interface to OSM in the original units. This has the advantage of displaying any existing mapping to the editor in feet. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Elevation in local units
On 3/25/15 1: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). +1 don't wait for all the consumers to catch up; you'll be waiting forever. richard -- rwe...@averillpark.net Averill Park Networking - GIS & IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ 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-24 13:57, Martijn van Exel wrote: I have long been on the fence about boundaries in OSM, and while I don't feel as strongly about it any longer, it still feels wrong to make this sweeping exception to one of the fundamental conventions of OSM mapping: verifiability. For many types of land use, anyone would be able to verify boundaries on the ground: a forest, a corn field, even a retail zone in most cases. But administrative boundaries can only be observed in a limited number of places: wherever there is a sign or a physical boundary in place, and rare other cases. Admittedly, a given border can be observable along one segment but not another. However, we tend to map the entire border for the sake of completeness, convention, and technical reasons -- closed areas are much more useful than stray lines. OSM has long gone to extremes on this point, going so far as to enclose all continents and island nations in maritime borders. Hopefully you had the chance to read my case study on Illinois, Indiana, Ohio, Kentucky, and West Virginia earlier in this thread. [1] You can observe much of the Ohio-Indiana state line quite precisely, both on the ground via welcome signs and mile markers and from the air via changes in land use and pavement quality. But you cannot observe the Ohio-Kentucky state line except by visiting a library, and the Ohio-Ontario border is an imaginary line. Which of the five options would you have chosen for Ohio? [1] https://lists.openstreetmap.org/pipermail/talk-us/2015-March/014485.html 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. All of this has little to do with neighborhoods, which are mostly (?) vernacular in naming and delineation, and even when there are official neighborhood designations, in my own experience they do not always match the vernacular names. I support point mapping of vernacular neighborhoods. If you really want to have shapes for vernacular neighborhoods, you can look at the now-ancient-but-still-cool flickr Alpha Shapes[2], last updated in 2011 but still available for download[3]. But please don't upload 'em to OSM :) As a political boundary (in the political map sense), an official neighborhood designation can be distinct from the neighborhood with a vernacular name, but that's an argument to map both rather than favoring one over the other. They coexist and might share a name but aren't necessarily the same thing. People should be able to get the concrete, objective boundary of an official neighborhood from OSM and an amorphous, subjective boundary of an informal neighborhood from Alpha Shapes. -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
