Re: [Talk-us] 'Michigan' lefts in Arizona
On Mon, Oct 07, 2013 at 06:26:27PM -0600, Martijn van Exel wrote: > Hey all, > > I was looking for more info on Michigan lefts (in particular, how many > are there?) and google offered up this gem here: > http://www.tucsonweekly.com/TheRange/archives/2013/08/29/theres-a-jingle-for-the-forthcoming-michigan-lefts-so-its-all-going-to-be-ok-now > So apparently these are not confined to Michigan. Anyone from the > Tuscon area mapping these or planning to? Are there any other > non-Michigan Michigan lefts? > Bit late to this, but I drove by one of the two intersections in Tucson they mention the other day and it's finished with construction and been changed to the indirect left (Grant and Oracle -- the indirect left is from Grant onto Oracle, either direction). I haven't been as far north as the other intersection, Oracle and Ina, to know. I'm confident that OSM isn't updated with this info, however, and I've no clear ideas about mapping. Just wanted to update on this for the curious. > Best, > Martijn > > -- > Martijn van Exel > http://oegeo.wordpress.com/ > http://openstreetmap.us/ > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us pgp1lbRQ64n90.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US: misalignments
Hi, For what it is worth, this is an example of a several different imports ignoring each other rather than a problem specific to admin boundaries. >> >> http://www.openstreetmap.org/#map=15/36.2642/-95.7297 > that is a good one. This is the same problem as above. http://www.openstreetmap.org/#map=16/41.7182/-69.9313 at least 4 different imports all not quite agreeing with each other. The entire coastline of MA looks like this. Jason. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
Agreed that we should not, under no circumstances, just go ahead and remove data from OSM that has been there for a long time, that people rely on. And that is not what I am proposing. Really, I am not proposing anything, I am just stating my opinion that authoritative data such as boundaries, for which a freely available resource exists, and which are not easily verifiable through surveying methods at our disposal, have no place in OSM. If it were up to me, we'd set up a data service (be it WFS, geojson or whatever floats our boat), make sure that service always has the latest data, (I'm sure we could work with Census to make this happen) and call that service as needed for tile generation, API calls, etc. It's a variation on your multi layer approach, I guess. On Sun, Nov 3, 2013 at 10:55 AM, Richard Welty wrote: > On 11/3/13 12:17 PM, Martijn van Exel wrote: >> Administrative boundaries are generally not verifiable by ground >> surveying, and are not straightforward to edit. This causes >> information rot. What good is administrative boundary information that >> are not trustworthy? Moreover, they are freely[1] and easily available >> from an authoritative source. For all these reasons combined, I would >> favor them not being in OSM at all. >> > on the other hand, people expect to see at least some of these > boundaries in a map, and apps like Nominatum and various > GPS apps (OsmAnd being one) use them. > > i understand your point of view, but removing them will be > very disruptive to a bunch of important data consumers. > > what i favor is going to a multi layer approach where some > layers of OSM are ground verifiable things and others may > not be. a consumer could choose to use some layers, and > the admin boundaries (which are a real problem) can be > moved and we can consider how to approach them differently > because what we're doing now isn't working real well. > > richard > > > > -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
Richard Welty writes: > what i favor is going to a multi layer approach where some > layers of OSM are ground verifiable things and others may > not be. E.g. the current openstreetmap.org and my suggestion of closedstreetmap.com. The difficulty of layers, as it has always been, is keeping them in synch with each other. Sometimes logical layers and physical layers need to line up with each other. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] NHD tags
Hi, I came across my first NHD imported data set this weekend, in Western MA. http://www.openstreetmap.org/browse/way/43638395 It has the following tags. NHD:ComID = 7711652 NHD:FCode = 39004 NHD:FDate = 1999/09/06 NHD:FTYPE = LakePond NHD:GNIS_ID = 00212194 NHD:GNIS_Name = Lake Winnemaug NHD:RESOLUTION = Medium NHD:ReachCode = 0115003135 gnis:feature_id = 00212194 name = Lake Winnemaug natural = water source = NHD The NHD wiki is pretty confusing. Is there is any kind of consensus on how NHD data *should* look inside OSM? Should any of these NHD tags even be maintained inside OSM? Also, the GNIS id is prefixed with 2 extra zero's. Is that OK, or ideally would that be fixed too? Thanks Jason. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
On 11/3/13 12:17 PM, Martijn van Exel wrote: Administrative boundaries are generally not verifiable by ground surveying, and are not straightforward to edit. This causes information rot. What good is administrative boundary information that are not trustworthy? Moreover, they are freely[1] and easily available from an authoritative source. For all these reasons combined, I would favor them not being in OSM at all. on the other hand, people expect to see at least some of these boundaries in a map, and apps like Nominatum and various GPS apps (OsmAnd being one) use them. i understand your point of view, but removing them will be very disruptive to a bunch of important data consumers. what i favor is going to a multi layer approach where some layers of OSM are ground verifiable things and others may not be. a consumer could choose to use some layers, and the admin boundaries (which are a real problem) can be moved and we can consider how to approach them differently because what we're doing now isn't working real well. A wonderful and broad topic. Richard's multi layer approach is laudable. A balance with legacy and syntax is to not be brittle and strict so as to strangle the future. Sure, you can do so and rewrite in the future, either that or think ahead. We use superrelations to describe semantic behavior (states and nations). Tags and "how it might make sense to consume these data" are often wildly different, when you get right to it. Political boundaries can be as fluid as flooded roads. I believe OSM wants a modicum of political and boundary data, whether parks, open space, wilderness, forest, city limit, neighborhood, etc. Data overlap like that is one thing that makes OSM so useful. It now sings beautiful choruses, has a few sour notes here and there, and everything in between. It tunes up here and now (and in a likeable way, if I say so myself). See, teasing out "how the data are used" and "what the data are" (are, AND will be) truly are relevant. CDPs are a wide weird animal. We could go on and on. In some cases they are better than nothing, in others they are noise and in still others they are better off left out or never entered. This is an educated guess, but it seems when uploaded OSM data meet criteria of Basic Quality, they stay uploaded. Maybe (we hope) they get updated with a new census or new TIGER or even new hydro data (OK hydro is much less a political animal being more landuse or natural), depending on the active local community of people saying "good enough for here." Or, "we intend to update if and when we get better and/or newer data." That's real, and a good sign in an OSM community when true. Often, (and another good sign, as it shows intention of priority) there is a list of what's next and dream topics, and how "those" get started. It's a conversation. Let's identify (prioritize) problem areas, problem specifics, common tagging errors in the syntax that can be harmonized and maybe better ways to determine date of (original, imported, if they were) data published. A much harder metric to start wanting to assign (but it could be proposed) is a quality or trust scale. This might vary based on the consuming applications specific appetite (geocoding, neighborhood, quarter, suburb, town, village, hamlet, isolated_dwelling, whatever). This way, data consumers have a hook to poll data selectively in a newer different way that should help their results. OSM already IS multi layer in a few senses, might we sharpen up the focus of how we rate or trust data? Like inventing a small tag syntax that largely captures good ways to describe (and hook) the now data, legacy consumers and the future? A terrific solution, and it seems a worthy yet difficult thing to do (achieving agreement from wide asking, designing the language tags can be easy or difficult...). This is especially useful as a large, wide goal is only over a longer term. If I know I should tweak a legacy algorithm today like this, I would: "reject CDPs from New York State." But you need to know to do that. How? A serious power in OSM is its free-form tagging (language writing ability). Data consumers who make sense out of many layers here, win. Tag appropriately. (And it goes without saying, upload appropriately). Designing little tag languages of wide and harmonious consensus? Which benefit data consumers and stay flexible for a future? Ah. Then again, there is nothing like a wonderful future where "many agree, OSM is awesome" is largely true. We take steps, we build bridges, we get there. (There may also be few, no or bad patterns to discern that well-crafted tag linguistics can help, though I hold out hope). We keep meeting in the middle: I like it! Good conversation. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/lis
Re: [Talk-us] Admin borders in the US: misalignments
On 11/3/13 1:57 PM, Frederik Ramm wrote: > Hi, > > On 03.11.2013 16:46, Richard Welty wrote: > > Misaligned borders - we have a lot of these > > This nice example was featured in "worst of OSM" a while ago and seems > to have been unchanged since: > > http://www.openstreetmap.org/#map=15/36.2642/-95.7297 that is a good one. right after i wrote those messages, i got my first close look at the spot where NY/CT/Westchester County/Fairfield County reach Long Island Sound. all i have to say is this: what a $#&#*!^&#*#*$*#**#*#*($(($($ mess. i have fixed the Westchester County line, but that's only a start. this is going to take a while. richard signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US: misalignments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 03.11.2013 16:46, Richard Welty wrote: > Misaligned borders - we have a lot of these This nice example was featured in "worst of OSM" a while ago and seems to have been unchanged since: http://www.openstreetmap.org/#map=15/36.2642/-95.7297 Bye Frederik - -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSdpyUAAoJEOx/uhGAJu9HstUH/3BLTrv6sx70IpVCopu9lKie YKNdKpSy9QF6pqA4QFSPW17K67jWhy3/E50PL+UKl1kPfxguaB0jpiqp0m4UH+EK bcUCUy70DofHAwqqanHYcFGPQzz1eBE+wju/yQ08NaRIFQlyt973N54xCR2wk9ya KnHlnjDWs3fmDoOmAjOBCPk33p0bBFF6ID3UOHRHgJA/ijtmSRBXzqyJiLTSeVcL fKAZb2OUs2Zmjq+b7oHCik72XBvmo49ofz1K+mv33/NTOVrGm7MKiIAGT67qxLDv feO1VPZoY4T4DPEYVaKDOhQJ7vVtkBXvQddDPdoL6jXoA8bZ4SOtR2a1DmxtWe4= =YTLW -END PGP SIGNATURE- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
On 11/3/2013 12:55 PM, Richard Welty wrote: what i favor is going to a multi layer approach where some layers of OSM are ground verifiable things and others may not be. a consumer could choose to use some layers, and the admin boundaries (which are a real problem) can be moved and we can consider how to approach them differently because what we're doing now isn't working real well. In some cases, the boundaries can be attached to physical objects in OSM, where that relationship is legal and known; there is some value in having it on the same layer. But being able to perform a wholesale update of boundaries from newer sources is valuable. Right now, all the cities and towns around me have updated their 'gerrymandering' style of annexation quite a number of times since the date of the boundaries that were imported. Because many those boundaries have been stitched to any nearby OSM object (rightly or wrongly via the remove duplicate nodes function), a re-import to our traditional layout would be a major undertaking. By contrast, updating them on a dedicated layer would be a simple task. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
On Sun, Nov 3, 2013 at 9:55 AM, Richard Welty wrote: > what i favor is going to a multi layer approach where some > layers of OSM are ground verifiable things and others may > not be. a consumer could choose to use some layers, and > the admin boundaries (which are a real problem) can be > moved and we can consider how to approach them differently > because what we're doing now isn't working real well. > I agree that a multilayered approach would be preferable. It would not only allow the user to choose the layers to display but make it much easier for new mappers. Boundaries do provide a benefit when analyzing osm data. Boundaries allow for measuring of features inside boundaries. To me one of the important reasons for having boundaries in OSM is for use with GPS units. Knowing that I'm in a specific jurisdiction is helpful. It might mean that I can expect to find answers to questions from the city or county. Or it might mean that I need to pay for a permit to take pictures on a Pueblo. -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
On 11/3/13 12:17 PM, Martijn van Exel wrote: > Administrative boundaries are generally not verifiable by ground > surveying, and are not straightforward to edit. This causes > information rot. What good is administrative boundary information that > are not trustworthy? Moreover, they are freely[1] and easily available > from an authoritative source. For all these reasons combined, I would > favor them not being in OSM at all. > on the other hand, people expect to see at least some of these boundaries in a map, and apps like Nominatum and various GPS apps (OsmAnd being one) use them. i understand your point of view, but removing them will be very disruptive to a bunch of important data consumers. what i favor is going to a multi layer approach where some layers of OSM are ground verifiable things and others may not be. a consumer could choose to use some layers, and the admin boundaries (which are a real problem) can be moved and we can consider how to approach them differently because what we're doing now isn't working real well. richard signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
Administrative boundaries are generally not verifiable by ground surveying, and are not straightforward to edit. This causes information rot. What good is administrative boundary information that are not trustworthy? Moreover, they are freely[1] and easily available from an authoritative source. For all these reasons combined, I would favor them not being in OSM at all. [1] At least in the case of the United States - except for periods of government shutdown. In other countries, like the Netherlands, there is no such easily accessible authoritative source for some boundary levels, in which case maintaining them in OSM makes more sense to me. On Sun, Nov 3, 2013 at 8:36 AM, Richard Welty wrote: > the scope of this series of messages is strictly confined to two > related things: true admin borders which are tied to local government > in a strict sense (that is, there is an actual elected governmental > body) and CDPs which are lumped in as admin_level 8 even > though they do not have elected governments (in NYS, these > correspond roughly to Hamlets, which are long established > named places without governments.) > > another upstate NY mapper and i have been cleaning up borders > in NY. it's been a long going and often tedious effort, and in > the process i've seen a lot of things. a bunch of discrete topics > follow in separate email messages so that we can focus on each > issue... > > richard > > > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US: proper construction of ways and relations
On 11/3/13 11:24 AM, Mike N wrote: > On 11/3/2013 10:54 AM, Richard Welty wrote: >> i've determined that a lot of the NY/PA border heading west >> from the Delaware has issues where no one bothered to break >> up and share the ways. > > Or, in my case, since I have no access to the "accurate and correct > border", and I have no idea where the border really is, I haven't > touched any of them. if you did want to work on them, the TIGER 2013 shapefiles are a way to get going. they appear to be the best source of borders available to us (short of the occasional cooperating County GIS department). not perfect, but better than what's out there, and so the map will be improved. richard signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US: proper construction of ways and relations
On 11/3/2013 10:54 AM, Richard Welty wrote: i've determined that a lot of the NY/PA border heading west from the Delaware has issues where no one bothered to break up and share the ways. Or, in my case, since I have no access to the "accurate and correct border", and I have no idea where the border really is, I haven't touched any of them. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Admin borders in the US: proper construction of ways and relations
i've determined that a lot of the NY/PA border heading west from the Delaware has issues where no one bothered to break up and share the ways. and i've seen a lot of early work which we would now consider mistagged. this all sort of plays together... the ways in borders should probably not have any tags at all. early borders frequently have a bunch of tags (type, admin level, source). but ways can be in more than one border relation and for rendering purposes they derive their appearance from the relations that contain them. relations should have the standard core tags, but they should not have the mess of TIGER: tags they got from early imports and they should not have source tags. source tags go on the changeset (i have not been entirely consistent about this myself and i apologize for that before anyone calls me on it.) using URLs for sources turns out to be kind of useless, as things move around on the net. a clear text description is better: source=TIGER 2013 NY Places Shapefile signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Admin borders in the US: misalignments
Misaligned borders - we have a lot of these early border imports came from multiple sources, and when they were done, it was rare to look at other border imports in the vicinity and clean things up. a good example is along the Hudson River, where the county borders were from USGS (which were not very good borders) and the places (cities, villages, CDPs) were from 2008 TIGER (better but not great). while the ways for the places were often shared properly by relations, the county borders were ignored because they didn't match and the result was that the border lines down the Hudson were an ugly mess. in updating borders down the Hudson, i've found that frequently 2013 TIGER borders are different (and largely improved) over 2008, and there is no reason to retain the USGS borders. likewise, i've similarly been replacing the USGS state borders with TIGER 2013 as needed. if anyone is foolish enough to take on these tasks, be aware of these things. in densely populated areas in particularly (Rockland County NY was bad and Westchester County may be worse) you may find a domino situation where you need to deal with a bunch of old, outdated place borders. Finally, one of the most festive situations i encountered was along the Delaware River - the NY/PA border. one early mapper used what looks like an NHD centerline for the border, which isn't necessarily a wrong decision, except it matched up with neither USGS county borders or any TIGER borders. for the sake of sanity this is now entirely TIGER 2013. again, don't do borders unless you are prepared to deal with the entirety of the situation that's in front of you. more on borders in the next note. signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Admin borders in the US: CDPs
first of all, CDPs. there's been an ongoing discussion about whether they belong in OSM at all, or whether they deserve their admin_level 8 classification. i have mixed feelings about the first, and am pretty sure we need a new way of classifying them if we keep them. here's some more fuel for the fire. one of the things i've seen in Westchester County is that between 2008 (the source for most of the current CDPs) and 2013, the Census Bureau rather substantially revised a bunch of CDP boundaries, mostly making them much, much smaller. so any 2008 CDP boundary is suspect for being way out of date. given that virtually no one is paying attention, that's a lot of stale, unmaintained data of marginal value sitting around. i'm updating the CDPs where i see these issues, but i'll probably miss some and i think we need to reopen the discussion about CDPs. signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Admin borders in the US
the scope of this series of messages is strictly confined to two related things: true admin borders which are tied to local government in a strict sense (that is, there is an actual elected governmental body) and CDPs which are lumped in as admin_level 8 even though they do not have elected governments (in NYS, these correspond roughly to Hamlets, which are long established named places without governments.) another upstate NY mapper and i have been cleaning up borders in NY. it's been a long going and often tedious effort, and in the process i've seen a lot of things. a bunch of discrete topics follow in separate email messages so that we can focus on each issue... richard signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
