Re: [Talk-us] Feature proposal: proposed expanded address tagging scheme for US
There are two fundamental questions (to me) in this issue which have not been explicitly asked or answered, either on the list or the wiki: - Will the "addr:street" tag on the address node or way have the exact same value as the "name" tag on the street way? - Are you proposing to remove directional prefixes and suffixes from the "addr:street" and "name" tags, or leave it with the fully-qualified complete value? I will start by saying that, to the first question, any proposal to put different values on "addr:street" on address nodes and "name" on the road is just plain stupid. That will make no end of trouble in trying to do anything useful like routing. So for this proposal, the stance should be state clearly. To the second question: I absolutely, fundamentally disagree that these prefixes and suffixes should be removed from the "name" and "addr:street" tags. Doing so is exactly what WILL make the names ambiguous. The name and addr:street tags should be full and complete with all prefixes, suffixes, and qualifiers. But the name and addr:street needs to be COMPLETE, since it is the universal lowest common denominator. The proposal to redefine the "name" tag as something less than the complete full name is not new. Kevin Atkinson has been redefining the name tag by removing prefixes from street names all over Salt Lake City for a while now. I'm really not understanding the arguments about naming ambiguity. I looked at Hickory NC. Two streets named "10th Street Place Northwest" and "10th Street Drive Northwest" are clearly different. What is ambiguous there? Four streets named either "10th" or "10th Street" with other tags to differentiate them will DEFINITELY be ambiguous. I think it is a great idea to add additional tags to specify prefixes, suffixes, or base names. I personally would like to see those added (or left/converted from Tiger tags). It would be great to see mkgmap enhanced to optimize prefixes and suffixes, for example. HOWEVER, having said all of this, I think the basic proposal for these address tags is just a bad idea. Let me explain why. All of the values for the street name components, on every address node, should be the same for all address nodes on the street. That could be dozens or hundreds for every single street in the country. Why duplicate these tags on every address node? You can GUARANTEE that the nodes will not be consistent; some users will maintain them one way, and some will maintain them another. A better way to do all of this is to have all of these new supplemental tags on the street way, and simply have the addr:street tag use the same value as the "name" tag on the street way. Or, use the associatedStreet relation. I know the hope is that some yet-to-be conjured tools will encourage or enforce the consistency across all the address nodes on a street. Such yet-to-be-created tool could just as well ensure that the values go with a proper street way, or an associatedStreet relation. Please, Please, PLEASE do not change or redefine the "name" and "addr:street" tags. They aren't overloaded, they are COMPLETE and UNAMBIGUOUS. Add whatever tags in addition you want. If you really want to add a million new tags on address nodes everywhere, I won't stop anyone, but I think it is redundancy that would be better handled on the street way. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] MapRoulette challenges wiki
> Even in Map Roulette, there are some places where I could have taken a larger > chunk, a single area with 5 connectivity errors is just as easy to fix; I > just got one such roulette spin, and wasn't sure if I should fix the others > or not, because there's no way to mark them fixed. Fix them anyways. It was explicitly recommended in the previous incarnation as remap-a-tron, because all the data was re-analyzed nightly. I'm pretty sure I read the same for maproulette. They'll get recognized as fixed, I'm sure. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Difficult USA mapper(s)
> We need to stop talking in nebulous terms. "the complaints here" are > apparently unknown to everyone. If it's not appropriate to describe the > specific issues, then perhaps we shouldn't be having this conversation on the > mailing list. Heh, one has to be quite new to talk-us to not know the likely suspect(s). Oops, I think my bias is showing. That notwithstanding, I think it is quite reasonable to discuss the DWG boundaries and guidelines without details of a specific conflict. It makes sense to discuss and decide what the purview *should* be, before you can decide if a given conflict falls within those boundaries. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] What to do with unnamed NHD streams
> What would be saved by dropping the nameless intermittent streams assuming > they were simplified? I expect this really varies by location. In my area (Washington County, Oregon) these streams were quite useless. Most of them were just plain gone, replaced by farm fields or suburban housing tracts. (Insignificant snow here also) Perhaps it would be worthwhile to make them available as a separate OSM file, which local mappers could import in addition to the main file. (yes, duplicated nodes, blah blah blah, josm verify->fix, big deal :-) - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Burlington, Vermont road classification
The crux of the problem is the answer to the question: Which is more >important, outside/official classifications, or physical characteristics? > >The tagging pages on the wiki don't really provide clarity on this >matter. > Although the wiki may not be very clear, this subject has been discussed extensively on talk-us in the last year or two. For the highway tag in particular, the consensus I've seen is that it is definitely more about the physical characteristics, "driveability", and perhaps perceived local importance than any government classifications. Yes, part of that is subjective. Highway=motorway in particular is about physical characteristics, regardless of being state, US, or Interstate highway. Primary/secondary/tertiary are more related to size and/or local importance, which sometimes matches gov't classifications but often does not. (Related to this is the "ref" tag, used to designate official route numbers.) - Alan___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map update - NOW working for me
On 9/29/2012 2:18 PM, Alan wrote: Anyone else have problems with recent versions of these no longer working for them? Um, sorry, false alarm. After completely clearing out my SD card, and making sure there were no left over recycle bin or hidden files, I tried it all again and it worked. Looks like just stupid user error on my part :-( (I do wonder if there was a more subtle explanation in the VFAT filesystem on the sd card, where the Nuvi may only read the DOS 8.3 short filename. I wonder if there is a scenario where one might copy a file to the card and then rename it, ending with a long name of gmapsupp.img and a short name of GMAPSU~1.IMG or something. Always looking for someone to blame other than me :-) Thanks for everyone's advice anyways! - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map update - NOW working for me
On 9/29/2012 2:18 PM, Alan wrote: Anyone else have problems with recent versions of these no longer working for them? Um, sorry, false alarm. After completely clearing out my SD card, and making sure there were no left over recycle bin or hidden files, I tried it all again and it worked. Looks like just stupid user error on my part :-( (I do wonder if there was a more subtle explanation in the VFAT filesystem on the sd card, where the Nuvi may only read the DOS 8.3 short filename. I wonder if there is a scenario where one might copy a file to the card and then rename it, ending with a long name of gmapsupp.img and a short name of GMAPSU~1.IMG or something. Always looking for someone to blame other than me :-) Thanks for everyone's advice anyways! - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map update - not working for me
On Sun, 2012-09-30 at 21:09 -0700, Dave Hansen wrote: > Could folks that are having trouble try some single > tiles or a set generated directly from Lambertus's site? OK, I tried directly from Lambertus's site. I tried the pre-defined state of Oregon from http://osm.pleiades.uni-wuppertal.de/garmin/generic/26-09-2012/98f98a467c2ca93389e891f40b15a33d/ and it worked. The Nuvi 200 recognized it as "OSM generic routable". I'm requesting a custom tile set now from there. We'll see what it does. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map update - not working for me
On Sat, 2012-09-29 at 17:48 -0400, Richard Welty wrote: > my Nuvi is relatively new (about 2 years old). how old is the firmware > on your Nuvi? Mine is rather old. Not sure about the date, but probably at least 5 years old. It just says "Nuvi 200, software version 5.00, GPS SW Version 2.20b". Next I'll try Dave's suggestion of going straight to Lambertus's site. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Remap-a-tron level 2 complete! Suggestions for level 3?
Another suggestion: motorways and trunks without lanes=number tags - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] JOSM zoom limits per server solved (fixes Tiger grey overlay )
I also found there is a minimum zoom also. Put it in the url as min,max like
tms[16,19]:http://...
Fixes the grey tiles when I zoom back out.
- Alan
On Sep 23, 2012, at 12:54 AM, Toby Murray wrote:
> I knew about the max zoom setting but for some reason never thought about
> applying it to the TIGER tiles to fix the grey
>
> Toby
>
> On Sep 21, 2012 1:23 PM, "Alan Millar" wrote:
> Maybe everyone else knows this, but I just discovered it myself so I
> thought I would share it.
>
> I've been using Remap-a-tron to fix up US roads. I use both the Bing
> imagery and the TIGER 2012 tiles overlaid, and it makes it really
> useful.
>
> However, I've been frustrated that I can pretty far in with the Bing
> images, but if I go too far, the Tiger (normally transparent) tiles turn
> grey and obscure the Bing images. I've been continually turning off and
> back on the Tiger layer, which is a bit annoying after a while.
>
> JOSM has an easy limit in the Preferences for the maximum zoom, but it
> affects everything. I set it to 19, and then I did not get the grey
> boxes from Tiger, but did not get the higher detailed photos from Bing
> either.
>
> As it turns out, JOSM does have a max-zoom per tile server feature; it
> just is not obvious or clearly documented that I could find.
>
> You can enter it as part of the TMS url like this:
>
> tms[19]:http://{switch:a,b,c}.tile.openstreetmap.us/tiger2012_roads/{zoom}/{x}/{y}.png
>
> The number 19, right up front, says that the maximum zoom to use for
> this layer is 19. This solved the whole thing for me.
>
> I also found that if you go into Josm preferences in expert mode, and
> dig and dig and dig into the imagery providers entries, this is labeled
> as max-zoom. Too bad it isn't easier to find.
>
> Anyways, hope this helps others too.
>
> - Alan
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] JOSM zoom limits per server solved (fixes Tiger grey overlay )
Maybe everyone else knows this, but I just discovered it myself so I
thought I would share it.
I've been using Remap-a-tron to fix up US roads. I use both the Bing
imagery and the TIGER 2012 tiles overlaid, and it makes it really
useful.
However, I've been frustrated that I can pretty far in with the Bing
images, but if I go too far, the Tiger (normally transparent) tiles turn
grey and obscure the Bing images. I've been continually turning off and
back on the Tiger layer, which is a bit annoying after a while.
JOSM has an easy limit in the Preferences for the maximum zoom, but it
affects everything. I set it to 19, and then I did not get the grey
boxes from Tiger, but did not get the higher detailed photos from Bing
either.
As it turns out, JOSM does have a max-zoom per tile server feature; it
just is not obvious or clearly documented that I could find.
You can enter it as part of the TMS url like this:
tms[19]:http://{switch:a,b,c}.tile.openstreetmap.us/tiger2012_roads/{zoom}/{x}/{y}.png
The number 19, right up front, says that the maximum zoom to use for
this layer is 19. This solved the whole thing for me.
I also found that if you go into Josm preferences in expert mode, and
dig and dig and dig into the imagery providers entries, this is labeled
as max-zoom. Too bad it isn't easier to find.
Anyways, hope this helps others too.
- Alan
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Large area of deleted streets in Riverside, Calif.
Here is a neighborhood that could be imported from TIGER 2012: http://www.openstreetmap.org/?lat=32.29183&lon=-95.4831&zoom=17 Thanks - Alan If most of it really is missing then it might be a good candidate to >re-import from new TIGER data as I have done in some other hard hit >areas of LA. It would help if you supply a permalink to the exact >area. > >___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] The Remap-A-Tron, Second Wave
Yes, that fixed it. Thanks! - Alan > > From: Martijn van Exel >To: Alan Millar >Cc: ">" >Sent: Monday, September 10, 2012 1:50 PM >Subject: Re: [Talk-us] The Remap-A-Tron, Second Wave > >Mweh. I suck at apache configuration. Try again, please? > >Martijn > >On Mon, Sep 10, 2012 at 2:42 PM, Alan Millar wrote: >> Quite a few hours later, I'm still seeing the 403 errors on those two paths. >> I've cleared browser cache and reloaded, with no improvment :-( >> >> >> Forbidden >> >> You don't have permission to access /remappingservice/count on this server. >> >> Apache/2.2.14 (Ubuntu) Server at lima.schaaltreinen.nl Port 80 >> >> >> >> >> From: Martijn van Exel >> To: Dale Puch >> Cc: Charlotte Wolter ; ">" >> >> Sent: Monday, September 10, 2012 6:44 AM >> Subject: Re: [Talk-us] The Remap-A-Tron, Second Wave >> >> What is your browser? Can you inspect the network activity on the >> page? Are http://lima.schaaltreinen.nl/remappingservice/ and >> http://lima.schaaltreinen.nl/remappingservice/count called and do they >> return valid (geo)JSON? >> Can you try a force-reload of the page? (ctrl-shift-r if you use Firefox) >> Does anyone else still have trouble? >> >> On Sun, Sep 9, 2012 at 11:52 PM, Dale Puch wrote: >>> Hmm Still seems stuck on the same location for me. I cleared my cache >>> just >>> to make sure that wasn't it. >>> >>> Dale >>> >>> >>> On Mon, Sep 10, 2012 at 12:44 AM, Martijn van Exel wrote: >>>> >>>> I repaired it - it was an apache config setting that was a little too >>>> strict. How'd that happen? Your guess is as good as mine. Bottom line >>>> is the Remap-a-tron works like a charm once more. >>>> >>>> Martijn >>>> >>>> On Sun, Sep 9, 2012 at 6:58 PM, Martijn van Exel wrote: >>>> > yea, something busted, I will look into it tonight... Hang in there >>>> > folks - and thanks for using! >>>> > >>>> > Martijn >>>> > >>>> > On Sun, Sep 9, 2012 at 6:50 PM, Dale Puch wrote: >>>> >> Not sure if it is just me, but this seems stuck today. All was fine >>>> >> yesterday. >>>> >> I only get one map location and it will not move to another with 'W' >>>> >> >>>> >> A few of the deleted ways have led me to some large missing >>>> >> subdivisions and >>>> >> poor downtown type areas... A bit of OCD kicks in and an hour+ later >>>> >> I'm >>>> >> finally done :p >>>> >> >>>> >> Dale >>>> >> >>>> >> >>>> >> On Sun, Sep 9, 2012 at 11:57 AM, Charlotte Wolter >>>> >> >>>> >> wrote: >>>> >>> >>>> >>> >>>> >>> I told Martijn the toold would be a great way to do Projects >>>> >>> of >>>> >>> the Month or Projects of the Week. Maybe there would be a way to >>>> >>> track >>>> >>> who >>>> >>> did what, so we can recognize people who did a lot of work. >>>> >>> >>>> >>> Charlotte >>>> >>> >>>> >>> >>>> >>> >>>> >>> At 02:20 PM 9/7/2012, you wrote: >>>> >>> >>>> >>> A fantastic tool! If it can be expanded to finding other issues even >>>> >>> better. >>>> >>> >>>> >>> Dale >>>> >>> >>>> >>> On Fri, Sep 7, 2012 at 3:38 PM, Martijn van Exel >>>> >>> wrote: >>>> >>> Hi, >>>> >>> >>>> >>> On Fri, Sep 7, 2012 at 12:37 PM, Serge Wroclawski >>>> >>> wrote: >>>> >>> > A similar query could be used to find overlapping ways which are of >>>> >>> > the same level and do not share a way. >>>> >>> > This could help with routing. >>>> >>> > >>>> >>> > There are a lot of queries like this which wouldn't be hard to do. >>>> >
Re: [Talk-us] The Remap-A-Tron, Second Wave
Quite a few hours later, I'm still seeing the 403 errors on those two paths. I've cleared browser cache and reloaded, with no improvment :-( Forbidden You don't have permission to access /remappingservice/count on this server. Apache/2.2.14 (Ubuntu) Server at lima.schaaltreinen.nl Port 80 > > From: Martijn van Exel >To: Dale Puch >Cc: Charlotte Wolter ; ">" >Sent: Monday, September 10, 2012 6:44 AM >Subject: Re: [Talk-us] The Remap-A-Tron, Second Wave > >What is your browser? Can you inspect the network activity on the >page? Are http://lima.schaaltreinen.nl/remappingservice/ and >http://lima.schaaltreinen.nl/remappingservice/count called and do they >return valid (geo)JSON? >Can you try a force-reload of the page? (ctrl-shift-r if you use Firefox) >Does anyone else still have trouble? > >On Sun, Sep 9, 2012 at 11:52 PM, Dale Puch wrote: >> Hmm Still seems stuck on the same location for me. I cleared my cache just >> to make sure that wasn't it. >> >> Dale >> >> >> On Mon, Sep 10, 2012 at 12:44 AM, Martijn van Exel wrote: >>> >>> I repaired it - it was an apache config setting that was a little too >>> strict. How'd that happen? Your guess is as good as mine. Bottom line >>> is the Remap-a-tron works like a charm once more. >>> >>> Martijn >>> >>> On Sun, Sep 9, 2012 at 6:58 PM, Martijn van Exel wrote: >>> > yea, something busted, I will look into it tonight... Hang in there >>> > folks - and thanks for using! >>> > >>> > Martijn >>> > >>> > On Sun, Sep 9, 2012 at 6:50 PM, Dale Puch wrote: >>> >> Not sure if it is just me, but this seems stuck today. All was fine >>> >> yesterday. >>> >> I only get one map location and it will not move to another with 'W' >>> >> >>> >> A few of the deleted ways have led me to some large missing >>> >> subdivisions and >>> >> poor downtown type areas... A bit of OCD kicks in and an hour+ later >>> >> I'm >>> >> finally done :p >>> >> >>> >> Dale >>> >> >>> >> >>> >> On Sun, Sep 9, 2012 at 11:57 AM, Charlotte Wolter >>> >> >>> >> wrote: >>> >>> >>> >>> >>> >>> I told Martijn the toold would be a great way to do Projects >>> >>> of >>> >>> the Month or Projects of the Week. Maybe there would be a way to track >>> >>> who >>> >>> did what, so we can recognize people who did a lot of work. >>> >>> >>> >>> Charlotte >>> >>> >>> >>> >>> >>> >>> >>> At 02:20 PM 9/7/2012, you wrote: >>> >>> >>> >>> A fantastic tool! If it can be expanded to finding other issues even >>> >>> better. >>> >>> >>> >>> Dale >>> >>> >>> >>> On Fri, Sep 7, 2012 at 3:38 PM, Martijn van Exel wrote: >>> >>> Hi, >>> >>> >>> >>> On Fri, Sep 7, 2012 at 12:37 PM, Serge Wroclawski >>> >>> wrote: >>> >>> > A similar query could be used to find overlapping ways which are of >>> >>> > the same level and do not share a way. >>> >>> > This could help with routing. >>> >>> > >>> >>> > There are a lot of queries like this which wouldn't be hard to do. >>> >>> > >>> >>> > - Serge >>> >>> >>> >>> Interestingly I was just discussing overlapping ways with Telenav >>> >>> yesterday. This will be a very useful thing to detect, but as these >>> >>> overlapping ways are not visible on the Mapnik map so the R-a-T may >>> >>> not be so useful for that. Some folks over at Telenav are developing a >>> >>> JOSM plugin that works in a similar way (iterating over error points >>> >>> pseudo-randomly and letting you fix them one by one) and may be better >>> >>> suited to these 'invisible' problems. >>> >>> >>> >>> Martijn >>> >>> >>> >>> -- >>> >>> martijn van exel >>> >>> http://oegeo.wordpress.com >>> >>> >>> >>> ___ >>> >>> Talk-us mailing list >>> >>> Talk-us@openstreetmap.org >>> >>> http://lists.openstreetmap.org/listinfo/talk-us >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Dale Puch >>> >>> ___ >>> >>> Talk-us mailing list >>> >>> Talk-us@openstreetmap.org >>> >>> http://lists.openstreetmap.org/listinfo/talk-us >>> >>> >>> >>> Charlotte Wolter >>> >>> 927 18th Street Suite A >>> >>> Santa Monica, California >>> >>> 90403 >>> >>> +1-310-597-4040 >>> >>> techl...@techlady.com >>> >>> Skype: thetechlady >>> >>> >>> >>> The Four Internet Freedoms >>> >>> Freedom to visit any site on the Internet >>> >>> Freedom to access any content or service that is not illegal >>> >>> Freedom to attach any device that does not interfere with the network >>> >>> Freedom to know all the terms of a service, particularly any that >>> >>> would >>> >>> affect the first three freedoms. >>> >>> >>> >>> >>> >>> ___ >>> >>> Talk-us mailing list >>> >>> Talk-us@openstreetmap.org >>> >>> http://lists.openstreetmap.org/listinfo/talk-us >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Dale Puch >>> >> >>> >> ___ >>> >> Talk-us mailing list >>> >> Talk-us@openstreetmap.org >>> >> ht
Re: [Talk-us] street prefixes
On Feb 17, 2012, at 2:58 PM, Paul Johnson wrote: > "Southwest Town Center Loop West" comes to mind as a great example of just > plain brain damaged street naming Wilsonville tends to have. You know, I should find out if I can see Mt Hood when driving east on Southwest North Dakota Street :-) - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Use of ref-tag on state highways
On Aug 21, 2011, at 11:08 AM, Nathan Edgars II wrote: > If you don't like it, you can always find a different country to armchair-map That's a little harsh. Where do you live now? New Jersey? Florida? Portland? L.A.? I can't keep track, but you sure get around to read a lot of signage. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another day, another bad import
On May 1, 2011, at 11:28 AM, Richard Weait wrote: > I think that is different in a significant way. It is much easier to > "fix a newbie" than to fix an import. Not if you start your conversation with them with "I hate newbies". That was my real point. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Another day, another bad import
On May 1, 2011, at 10:25 AM, Toby Murray wrote: > Every time I go editing in some new place, I always find another > reason to hate imports. Yeah... Every time I go editing in some new place, I always find another reason to hate newbies, too. If you are looking for a reason to hate something, it's always easy to find them. Human nature. Perhaps it's not the most constructive outlook, or discussion, to have. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD data import question
Well, it's been a while since I worked on it, so I can't recall exactly. But as I recall, there were things like, say, a small pond made up of a hundred nodes when 20 or so would suffice. Or pretty straight lines with nodes at closely spaced intervals, where all but the first and last were completely superfluous because they were all in a line. That sort of thing. It is not that there is any sort of magic number which is the right number of nodes. It is just that there were a lot more than were needed to adequately show the shape. JOSM's "simplify way" command has some calculations it does, mostly around looking at the angles between adjacent nodes I think. I don't remember the details, but I would recommend reading up on how it does it. - Alan - Original Message ----- > From: Ben Supnik > To: Alan Millar > Cc: "talk-us@openstreetmap.org" > Sent: Thursday, April 28, 2011 1:58 PM > Subject: Re: [Talk-us] NHD data import question > > Hi Y'all, > > What qualifies as too many nodes? Do we have metrics for this? I can > apply some kind of simplification if we can quantify what we want... > > cheers > ben > > On 4/28/11 4:34 PM, Alan Millar wrote: >>> I've been checking some of the imported data and my general feel is > that it is >>> overdigitized. I don't know if medium versus high reflects just > the quality or >>> the amount of digitization. That would be something to check. One > could also >>> just run some sort of simplification algorithm on all the data. >> >> >> I definitely found this to be the case for some parts of the >> area I did (Washington County, Oregon). >> >> >> I particularly remember it on >> areas like ponds and lakes; not so much on rivers and streams. Most of > them were reasonable, but a fair >> number of them had way too many nodes. >> >> >> I used the JOSM "simplify way" quite a bit, which worked > perfectly in my opinion. >> >> It may be analogous to TIGER, in that NHD may have a composite dataset that > got created in multiple ways. It may show up more in some places than others. >> >> >> - Alan >> >> >> ___ >> Talk-us mailing list >> Talk-us@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-us >> > > -- > Scenery Home Page: http://scenery.x-plane.com/ > Scenery blog: http://www.x-plane.com/blog/ > Plugin SDK: http://www.xsquawkbox.net/xpsdk/ > X-Plane Wiki: http://wiki.x-plane.com/ > Scenery mailing list: x-plane-scen...@yahoogroups.com > Developer mailing list: x-plane-...@yahoogroups.com > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] NHD data import question
>I've been checking some of the imported data and my general feel is that it is >overdigitized. I don't know if medium versus high reflects just the quality >or >the amount of digitization. That would be something to check. One could also >just run some sort of simplification algorithm on all the data. I definitely found this to be the case for some parts of the area I did (Washington County, Oregon). I particularly remember it on areas like ponds and lakes; not so much on rivers and streams. Most of them were reasonable, but a fair number of them had way too many nodes. I used the JOSM "simplify way" quite a bit, which worked perfectly in my opinion. It may be analogous to TIGER, in that NHD may have a composite dataset that got created in multiple ways. It may show up more in some places than others. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed cleanup: NHD "rivers"
On Mar 22, 2011, at 9:17 PM, Paul Norman wrote: > This is now complete for the area west of Portland Oregon as a test. > > http://www.paulnorman.ca/blog/?attachment_id=96 shows the difference. Nice improvement! I like it. > About 99.8% of the data was untouched since it was imported. I checked the > other dozen or so ways by hand. I did that import, and did a lot of cleaning up as I was importing it. So I think that probably reduced the amount of cleanup that anyone needed to do later. But I definitely felt at the time that the source data and value translations were a little vague. I really like the current proposal and example results. Looks great! - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Request for community mediation
>> I've spotted the consensus. Stop your bickering. Either come to an >> agreement about this tagging, or ignore each other, but absolutely >> stop picking on each other. > > You and Frederick seem to be the only ones with that view who > contributed to this thread. As Ian said, the rest of us just haven't been stirring the pot. I agree with Richard and Ian. While I like the Wikipedia concept of "be bold in editing", we don't need edit wars. I personally have been a contentious troll myself at times, and I find I need to back off, take a breather, and chill out some. I think both of you would benefit likewise, and OSM would be better off. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Feature Proposal - RFC - Directional Prefix & Suffix Indication
On Tue, 2010-08-24 at 01:40 -0400, David ``Smith'' wrote: > Maybe we should use signed_name=* or name:signed=* to store > exactly what's on the sign, preserving abbreviation and prefixes where > present? I found N. Temple, No Temple, and North Temple on city street signs all within a few blocks. Which one goes in the tag? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Thu, 2010-08-12 at 13:57 -0600, Kevin Atkinson wrote: > My main goal was to separate out the directional prefix because, which > while important for mailing, did not really belong as part of the street > name. I thought I would take care of the suffix as well. You may think it doesn't really belong as part of the street name, and that may possibly be true in your neighborhood. But in my neighborhood, it definitely IS part of the street name and can't be left off, for mailing or not. In my part of the Portland area, SW Takena is a completely separate unrelated street from NW Takena. In Seattle, Forest Ave S is completely separate and unrelated from Forest Ave SE. So I disagree, it does belong as part of the street name. If you have a prefix or suffix that you think is optional, don't call it the directional prefix or suffix that the rest of the country uses; we have them for a reason. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 2010-08-07 at 22:35 -0600, Kevin Atkinson wrote: > For those voting +1 have you even read my original proposal on the reason I > want to abbreviate? Yes. You gave a list of reasons it would be OK, and rules people would have to follow to make it work. Some of the reasons I consider suspect (such as "almost always in small letters" is a subjective, regionally-variant assessment). Other reasons were more rules and restrictions (such as period after single-letter abbrevs.) OSM is hard enough for people to get consistent on already. Keep the name tag unabbreviated. You certainly CAN have all the abbreviations you want. I'm just saying not to put them in the "name" tag; put them in another tag. I personally don't care if it is loc_name, alt_name, name_2, name:en, abbreviated_name, or whatever else you want to call it. Then work on getting the renderer to show it instead of the "name" tag when it exists. Why isn't that a good solution for you? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
How about this proposal for US streets: (1) Leave "name" unabbreviated (2) Put whatever form you want of abbreviated name in "name:en" Thoughts? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 2010-08-07 at 13:15 -0700, Paul Johnson wrote: > I vote for > 3) It's there for good reason. If you want abbreviations, tell your map > renderer to garble the data for you. Pre-garbling the data complicates > other usage scenarios. Don't do it. +1 Call me an "abbreviation police" if you want. But you can make software reliably abbreviate things; you can't make it reliably unabbreviate things. If you think you really need abbreviations, you need to work on the renderer, not the tags. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A Friendly Guide to 'Bots and Imports
As I manually survey various features (POIs, some hydro, etc.), I usually try to merge in the data from existing imports so as to maintain the link (e.g. gnis:feature_id) back to the original database, in case we want to exchange updates with them again. this is impossible due to the license terms, That may be the short quick answer, but it is not the long answer. The link will be valuable as we figure out other ways to synchronize the data and/or make dual-license updates; either originated from OSM or from the other party like USGS. Simple? No. Impossible? No. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] How to get college students involved?
On Fri, Aug 6, 2010 at 10:51 AM, Stefan Brandle wrote: >I suspect that reading all available documentation might be a good > start. :-) > It might, but it also might get you bogged down too. Two years into this myself, I'm still uncovering corners of "all available" that I didn't know were there :-) I definitely endorse jumping in and trying out the parts you can figure out (as it sounds like you're doing), while continuing to read/learn in parallel. For ponds in particular: one part of OSM I did not understand at first was that areas are the same as ways; they just connect beginning to end. So to draw a pond, make a way around the edge of the water (presumably tracing aerial photos) and connect the last node to the first node. The only thing that distinguishes an oval area from an oval track is the tagging. Tag the pond as natural=water, and you are done. Be sure to keep the wiki Map_features page handy. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Jul 29, 2010, at 5:41 PM, Anthony wrote: In any case, I disagree that it's better to leave information you know to be wrong in rather than deleting it. Perhaps that's our fundamental disagreement. For my part in the conversation, I *agree* with you that people should delete (or fix when possible) information that they know is wrong. But that is not the (or my) fundamental disagreement. My disagreement is on the deletion of *all* tiger: tags, because you don't see a need for them or you don't like the namespace or they don't fit your view of what/where/how they should be documented. As for tiger:name_base, tiger:name_type, etc., if there's someone that's using that information, we definitely should take it out of the tiger namespace. I'd be happy to move it from tiger:name_base=* to name_base=* instead of deleting it, if someone is using it and would take 5 minutes to put something up on the wiki announcing it. If it's useful, then it's useful for non-tiger ways as well as tiger ways. Yes, it is useful for non-tiger ways as well. And I will bet it will be useful for other countries besides the U.S. also. I haven't seen a conclusion on what people want to see in the naming convention (see for example the thread at http:// lists.openstreetmap.org/pipermail/talk-us/2010-April/003138.html). Just because the conversation is ongoing, that doesn't mean you need to delete the data in the meantime. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, Jul 29, 2010 at 4:55 PM, Anthony wrote: > On Thu, Jul 29, 2010 at 7:49 PM, Alan Millar wrote: > >> Furthermore, don't store redundant data in the OSM database. There's > >> absolutely no excuse for having 200 ways which all say name=Cain Rd, > >> name_base=Cain, name_type=Rd. It's absolutely terrible design. > > > > Patches welcome. Please contribute a fix. > > I've been fixing it. The fact that "Cain Rd" has a base of "Cain" and > a type "Rd" is already in the database over and over and over again. > I've been taking out the redundant copies of that information (which > should have been in a separate lookup table from the beginning > anyway). > But if you haven't created the separate lookup table and the concrete link from each such way in OSM to an entry in the table, and made the software support it, you haven't *FIXED* it! You already said that the TLIDs aren't useful and that you're deleting them, therefore there isn't a link back to TIGER. What positive contribution are you making to the data to ENABLE the name segmentation information on ways (that is already there in OSM, or was before you deleted it, even if redundant)? The reason that OSM does NOT enforce limits on tags is so that people can process the data in more ways that you or I can imagine in advance. While the name_base=Cain, name_type=Rd may be redundant, it can also be PROCESSED BY PROGRAMS AND SCRIPTS. When you delete this and don't provide a functional replacement that can also be processed by programs and scripts, you are removing useful information. Telling someone to go look it up in TIGER, when you don't provide a linkage to a specific TIGER record in the data, is NOT something people can process in a program! Just because you aren't processing the data like that, doesn't mean that somebody else isn't, or doesn't want to, or won't in the future. Specifically, RIGHT NOW, you are screwing with my ability to improve mkgmap. Stop deleting them until you provide a better replacement functionality. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
> > Furthermore, don't store redundant data in the OSM database. There's > absolutely no excuse for having 200 ways which all say name=Cain Rd, > name_base=Cain, name_type=Rd. It's absolutely terrible design. > Patches welcome. Please contribute a fix. So come up with a better design, define it in the wiki, and I'll keep it. > Wow; that sounds really rude. "Somebody else fix and document it the way I want, or I'll keep stomping on it." - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Roadway Classification Guidelines
>> >> set of guidelines at: >> http://wiki.openstreetmap.org/wiki/United_States_Roadway_Classification_Guidelines I read the whole page, and this is the first comprehensive narrative I've seen that makes sense to me for mapping highway tags on US roads. This is a good proposal. It looks clearly like more of a process description than a hard definition of tag values, but I believe that is necessary for the highway= tag in the US. >The proposal linked here suggests that mappers tag roads classified by > the government with certain highway= tags. I didn't get that interpretation from it. The proposal qualifies govt classes as "for the first iteration", followed by further rounds of re-evaluation and refinement. >But that doesn't mean a two lane at-grade > highway should be coded the same in one area as a four lane limited access > highway in another. Agreed, but I didn't read such an extreme disparity in the proposal. In contrast, a two-lane at-grade country highway in one area *should* have the same highway= tag value as a 4-lane urban boulevard in another area, when neither are limited-access freeways nor residential streets but do have similar local significance. >> We have those tags: lanes=*, width=*, etc. But there's no "on the >> ground" definition of importance, > > Yes there is. It's the highway= tag. I think the point is that the highway tag is *not* an "on-the-ground" definition, because you can't go out to every road in the US with a camera and measuring tape and say "This sign or measurement right here tells me exactly that this road is a primary/secondary/tertiary". Some values are pretty clear, such as motorway and residential. But others only have general correlations, such as a US highway is likely or often a primary or secondary, or a county highway is likely or often a secondary, and a big suburban street is likely or often a tertiary. But there is no exact measurement of importance, so it is subjective. But that is OK. The highway tag doesn't NEED to be an exact on-the-ground measurement or classification. It needs to be a one-word summary that most people will find useful for navigating through the area by car, bike, or roller-skate. Further clarification of the road, such as government classification and detailed physical properties, should come through other tags *in addition* to the highway tag (ref=, lanes=, width=, surface=, access=, route relations, etc). >> and there's nothing wrong with >> tagging correctly for the renderers. > Yes there is. "Tagging for the renderers" is the first thing people in OSM > will tell you *not* to do. OK, now this is getting silly. People are told not to tag *incorrectly* to force a particular appearance from the renderer. Nobody is told not to tag *correctly* when it matches what people want to see rendered. >> Classification has been >> subjective from the beginning in the US, because there is no >> consistent government-assigned classification. > That is incorrect. There is a relatively consistent government-assigned > classification system. There is one US federal, fifty state, and a thousand county classification systems, and they don't consistently define road standards across the entire country. Only US Interstate is pretty clear and unambiguous. "Classification has been subjective because..." means that you can't take any government-assigned classification that we have in the US (US highway, state highway/state route, county highway/county road), and say it *always* reasonably determines useful values of highway=trunk/primary/secondary/tertiary. It can only be a good starting guess, no more. > The suggestion I made > in my first reply to this thread was that we use a separate tag to describe > what the US government calls the way. I think most everyone agrees. It is mostly reflected already as the ref= tag or a route relation. I don't think most people would object to additional tagging for it. You know, I think people are more in agreement on the whole subject than it appears from these discussions. The emails look like a lot of disagreements, but perhaps it is more wording than actual disagreement on the ideas and substance. - Alan -- Alan Millar a...@bolis.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Oklahoma WMS?
> Does anybody have sources for license-compatible WMS servers in > Oklahoma? All I am aware of is the USGS data, which is very out of date > to the point of inaccuracy around Tulsa and OKC. I've found the USGS choices confusing on how to find the right thing, until recently. This page appears to have the most up-to-date images: http://seamless.usgs.gov/wms_services.php?layerid=15 According to http://imsortho.cr.usgs.gov/WMS_Capabilities/USGS_EDC_Ortho_Oklahoma/capabilities_1_1_1.xml?REQUEST=capabilities&SERVICE=WMS it's 2007 for Tulsa and 2008 for OKC. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Regional Street Centerline Solution - Minneapolis- St. Paul metro area - RFP
> Hi talk-us: For those of you who might have skipped over this simply > because it seems difficult to do, I ask that you at least skim over the > sections in Exhibit 1 of the PDF. As OSM gets more attention from groups > interested in using it, it's important to realize that the things requested > in this PDF aren't all that crazy and probably would make for a good source > of ideas for improvements to OSM's infrastructure. I agree. It is a very interesting idea, and yes, it does sound difficult, and also compelling for good improvements. In the near term, I personally have a hard time picturing "the community" maintaining the detailed rigor that would be required to meet the Metro's needs. In particular, OSM ways can be split and combined quite easily as needed for OSM usage, but this is a data nightmare for cross-referencing to other data sets. Bunch of TIGER lines + combine into one OSM way with a string of TLIDs in a tag + move, add, delete nodes to align with misc aerial photos - split way at every turn restriction and speed limit change or lane count change = cross-reference barf... While I like the general idea that OSM forgoes the traditional GIS layers in favor of the tag free-for-all, this is one of those times where the hard segmentation of data is probably necessary. You would need some serious edit controls to make it effective. Adjunct databases would seem to be necessary to maintain this. Look at TopOSM; sheer beauty. Anyone notice that US address search *IS* available on maps.cloudmade.com? Hmmm... (I'm hoping open mapquest does the same, too.) Having said all that, I *love* the idea of TIGER lines imported into OSM, getting cleaned up, being supplied back to Metro, to be fed back to the Census Bureau. I hope somebody can pull this off. This seems like an excellent project for a small OSM-savvy professional firm, or Cloudmade, or similar. Maybe AOL wants to start a patch.com branch in Minneapolis along with an open mapquest project. - Alan -- Alan Millar a...@bolis.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] simple osm-merge.sh updated for multiple files
andrzej zaborowski wrote: > There's a dummy script at > http://repo.or.cz/w/ump2osm.git/blob/HEAD:/osm-merge to do that (would > need to be modified for >2 layers). Here is my updated version of osm-merge.sh I also changed it to process files using double-quotes " " as I get from shp-to-osm.jar -- #! /bin/bash # Copyright (C) 2009 Andrzej Zaborowski # # Merge two .osm files without applying fancy logic (JOSM merge layers # operation tries to be too smart and corrupts data - see bug #2245) # # Updated 2010-07-11 by Alan Millar - accept more than two files # Process double-quotes if [ $# -lt 2 ]; then echo Usage: $0 a.osm b.osm ... \> new.osm >&2 exit fi echo "" echo "" FileNumber=0 while [ $# -gt 0 ] do echo "File $FileNumber $1" 1>&2 cat "$1" \ | grep -v -e '" -- - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Aeroway=Aerodrome Modifier Tags?
> Either the US has a much greater density of airfields/airports than > other parts of the world, I don't know about that. > many airfields/airports have yet to be mapped in > other areas of the world, Yes, definitely. > or the GNIS import brought in a bunch of airfields > that are no longer in operation. > Has anyone noticed a bunch old airfields in their area created by the GNIS > import that really shouldn't be on the map. I don't know if it is a bunch, but they certainly are there. I did a little research last year, and it looks like the GNIS list came from an FAA list. It appeared to include such things as clearance requested and granted for airstrips but never built, and former airstrips that have since been replaced by new construction. > All I know is that when I look > at the aerial imagery where some of these airfields/airports are supposed to > be, all I see is a field. Could be that it's just a grass runway?. Those do exist. Whether they merit inclusion on the map is subjective. I think the large/medium/small size suggestion is a really good idea. > In my > town there's one airport that's supposedly in the middle of the golf > course. There are some golf resorts with their own airstrips. But if you know the area, and know there is a golf course there and no airstrip, by all means feel free to fix the map and delete the obsolete airport item. Thanks for keeping an eye out for this stuff. - Alan -- Alan Millar a...@bolis.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Resigning in protest
> the LWG > has been going through peoples legitimate and illegitimate concerns for two > years I think it's been now. We've had lawyers checking everything at every > step of the way. I personally just want to say thank you to the license working group for taking on the thankless job of wrangling the legal issues and trying to plug the holes in the intellectual property issues. I am so sick of the intellectual property parasites these days like the patent aggregator trolls, the DMCA-weilding EULA writers, the virtually-perpetual-copyright-extension legislators, the corporate execs who fund these legislators and then monopolize business through it, the @#$%$ratzle#$%!fratzin'!...@*&?!!Oops, sorry, I got carried away there. (At least Darl McBride finally got canned; it only took how many years and how many millions$$$? Ugh.) Anyways, thank you to the OSM LWG and the Creative Commons and ODbL people who use their powers for good instead of evil :-) - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] HI: Hawaii GIS Data
Perhaps I'm not a typical mapper, but I don't find the existence of bulk imported local data to have been particular inhibiting in my activity level. I don't believe there is any one thing as a "typical mapper". But I certainly agree with you myself, and so do many others, as witnessed by many past postings to the talk-us list. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] HI: Hawaii GIS Data
> Please take a read of > http://www.gravitystorm.co.uk/shine/archives/2009/11/10/the-pottery- > club/ It started out as an interesting story, until I got to the "outsiders". Outsiders?!?! You have GOT to be kidding me. Next are we going to have a manhood contest about who has the longer, um, OSM pedigree? OSM is bigger than one little club. Are you and Andy going to come and survey my neighborhood? No, because you aren't *here*. But I am *here*, and I've got some neighbors here, and collectively we want to import starting data and we are happy with working with it. Believe it or not, somehow we managed to figure out how to find the "delete" key on our keyboards. Here's a better analogy: you and your friends started a pottery club in your town, and now you want to tell me what I can do with the pottery club in my town. Yes, I have 10 unfinished vases outside my back door that I got for free, but I'm not supposed to give them to any of my 300 million neighbors who don't know how to do pottery yet; they have to wait to have a vase until they make it themselves from scratch. That sounds a little unreasonable to me. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Fri, 2009-11-20 at 06:07 +, talk-us-requ...@openstreetmap.org wrote: > Heh, I didn't even know we had Oregon data available. We didn't at the time. I checked. Metro had (still has) restrictive licensing, and the state did not have any clearing house at the time. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Karlruhe Scheme addressing ways from 2009 TIGER data
> no one is interested to cleanup crap after a bad import. I am. > tiger import was great from technical > point of view but didn't allow to build a community from scratch. I didn't want to build anything from scratch. I'm simply not that motivated to go out and wander everywhere mapping everything. If we had to start from scratch, I would not do it. > no > one is motivated to fix this broken data. I am. I have fixed a lot of it. And in doing so, I have made complete, correct map areas, much larger than I ever would have done by starting from scratch. Be careful about making absolute generalized statements like "everyone" and "no one". - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing Alignments in JOSM
> However in reality it is a staggered junction. > > So I need to split the North-South way into two pieces and it intersects > the East-West way in two places. Depending on how far off the stagger is, you also may want to consider not splitting it, but just aligning the streets with two extra nodes. I've come across this where the stagger is small, and feels like it can still be considered one intersection. Here's an example of several intersections like that within a few blocks of each other: http://www.openstreetmap.org/?lat=45.56144&lon=-122.65675&zoom=17&layers=0B00FTF Your taste may vary; it's just an alternative suggestion. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addresses and Tiger
> > While a relation on the street could be useful for most addresses, it is > > not sufficient for all. There is nothing stopping anyone from > > implementing both, though. > i don't understand what this would mean in practice -- doesn't it just > mean that data would have to appear twice in the database, and/or the > renderers would need to render based on two different schemas? Implementing both does potentially mean that data could appear twice in the database. I wouldn't worry about the computer processing costs of that. I would worry about the data accuracy and human processing costs of maintaining it. (If the database contains both a Karlsruhe-style addressing way and some other relation-based form, and a user moves an addressing node or interpolation point, does the user update both data sets or will it require smarter tools in JOSM, Potlatch, and Merkartor to maintain it automatically?) The renderers would not necessarily need to render both forms. OSM as an architecture says that the Osmarender and Mapnik renderers are an important but only partial part of the total usage of OSM data. Either of the two could display addresses on a rendered map using either Karlsruhe nodes and ways, or a relation-based system. As far as I know only the Karlsruhe form is implemented but like all open-source projects, it is just waiting for an implementor for the other. However, the bigger issue under discussion, I think, is not how those two renderers draw pretty pictures, but rather how will routing software make use of the address information to provide routes. There are a number of routing programs which are looking for this data. There is openrouteservice.org, local software like Navit and Traveling Salesmen, and some people's Holy Grail of routing, Garmin GPS onboard routing. Any one of these users could be implemented to make use of either Karlsruhe-format data, relation-based data, or both. None of them must implement both but are free to do so if they want; it is up to the authors of the various tools to choose which they want to make use of. So this is a parallel-path of how to people want to enter and store the data, and how people want to extract and make use of the data. OSM can certainly support both, but I have a feeling that people are likely to converge on one or the other, and Karlsruhe seems to have the edge at the moment. Has anyone actually done ANY implementation of a relation-based addressing system in OSM yet? I've yet to see any actual examples of either data collection or use; I've only seen wiki proposals so far. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addresses and Tiger
> Can/should this be done with relations instead of separate paths? The > idea is to have it stick to the road. With this it creates a lot more > nodes, and there is no easy way to manually get the spacing right > between the road and the addresses if something is moved. Also the > spacing needed is render dependent. Can it be done with relations instead of [or in addition to] separate paths? Yes. Should it be done instead? No. Sure, the majority of addresses are for houses that are easily, unambiguously identified with the street that their address belongs to. But reality I've seen is that there are great numbers of exceptions, and so the Karlsruhe schema is necessary to indicate where an addressed building actually is. Take a look at the Clackamas Corner library: http://www.openstreetmap.org/browse/node/365787985 Now find its street, SE 82nd Ave. It is more than half a mile away. And the library is in a strip of stores, so an addressing way would/could apply here. While a relation on the street could be useful for most addresses, it is not sufficient for all. There is nothing stopping anyone from implementing both, though. > Wouldn't having the addresses connected to the road better for routing as > well? I haven't seen any actual implementations with a relations-based system, so I couldn't say if it would be better. But openrouteservice.org has already implemented it with the Karlsruhe schema. For example, see openrouteservice.org and put in start: Karlsruhe Julius-Bergmann-Straße 5 end: Karlsruhe Ellmendinger Straße 60 It clearly routes well, using the interpolation ways. And in the case of the Clackamas library above, SE 82nd Ave is not the best way to get to the library from quite a few directions, so the Karlsruhe scheme will work better. Now we just need to convince openrouteservice.org to expand outside Europe :-) Regards, - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Addresses and Tiger
> I have been playing around with the TIGER 2008 data, which, for some of > the counties around Atlanta seems to be much better than the old data. > If I import it for some of the counties, though, I would like to import > the addresses in a format that would be usable for routing software. > The most popular schema seems to be the Karlsruhe Schema, but making use > of it would require generating three OSM ways for each TIGER way - one > on either side to represent the houses on that side of the road. That > seems unnecessarily complex, but there does not seem to be any widely > accepted schema that places the data on the way itself. Does anyone > have any thoughts on that question? I had the same thoughts on the Karlsruhe schema. Having 3 ways for street and address interpolation does seem complex. But when I look at OSM areas mapped using it, and also recall problems I've encountered with geocoding, I think the Karlsruhe schema works pretty well. (At least if we keep full street information on the addressing ways, and not just the house numbers.) I've also been thinking about how to retrofit the addressing data to existing areas which have already been edited and/or adjusted. Having multiple TLIDs per way, and then having ways split and/or recombined, will make it difficult. Just having multiple TLIDs per way could be hard, when the way has been moved from its original Tiger location. We'll have to interpolate the interpolation points, I guess. Hmmm - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Portland, OR Mapping Party June 20-21
I heard there will be a mapping party in Portland, OR in a few weeks, organized by Hurricane McEwen of CloudMade. Portland, OR Mapping Party Saturday June 20, 2009 at 11:00 AM until Sunday June 21, 2009 at 4:00 PM See http://community.cloudmade.com/event/custom/generic/show/179 - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] What, exactly, does the absence of tiger:reviewed=no mean?
I think the quality standards of OSM are subjective, and continuously evolving (at different rates in different areas), but that doesn't mean we can't have a reasonable consensus on basic map usability. > I would expect that removing review:no means something in between > > ?"this is now done about as well as I would have expected someone to do > ?it in the first place" > > and > > ?"this is now good enough that there's no reason for anyone else to > ?worry about it" I think that is actually a fairly good definition. If someone really, really needs more specifics, then we should put them on a wiki page, perhaps http://wiki.openstreetmap.org/wiki/TIGER_fixup - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Blame me for JOSM yellowness
> I'd also be very happy if JOSM flipped the tag for me when I edit a > tiger object. It seems reasonable enough that if I'm editing something > that we can consider it reviewed. I certainly don't want to have to go > flip it manually every time I go fixing some minor road details. Good idea. (I would personally prefer to be configurable. Sometimes I align a road from aerial photo but want to remind myself to actually visit it later because something in the photo is unclear, so I leave it at reviewed=no.) There are two things I do currently to help in the cleanup: search and presets. In JOSM, you can search on the word "modified" and it will select all items you modified. Select the tiger:reviewed tag and delete it. If any of the modified items didn't have the tag, it doesn't hurt anything. And of course, you can select a rectangular region on the screen and do the same tag edit. I also made myself some JOSM tag presets and stick them on the main button bar. In each one, I set the tiger:reviewed value to blank, which will delete the tag if it is there. Here are some examples of mine: and so on. So before uploading: modified I wonder if I can shorten that even more? Hmm... - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Blame me for JOSM yellowness
> can you give a single example where this info is helping? It may not help you anywhere. It helps me everywhere, in my personal mapping process. > the tiger data is terrible wrong in some places. it's more important > to fix the data instead of spending time on a useless tag. Of course the Tiger data in OSM is terribly wrong in many places. It is also subtly wrong in many places, which can be harder to find and correct, or can be acceptable. It is also correct in many places, some of which were correct in the original Tiger, and some of which have been corrected by OSM mappers, sometimes by me, and sometimes by somebody else. You are free to edit as you prefer, but I need a way to keep track of this. I don't go on comprehensive mapping expeditions like my UK colleagues. I do incremental edits based on various trips that are incidental to the rest of my life. I try to clean up the map on and around the GPS track that I captured, based on what I saw and what I know of the area. If I see a nearby street on the map that I or another mapper has looked at before, I don't need to scrutinize it. If no OSM mapper has looked at it, I will check it out. Sometimes by aerial photo if I know the area or the pictures are clear with few tree obstructions. Sometimes I have to go visit the street, but I may not do it soon, or somebody else might do it. For this process, I find the tiger:reviewed=no tag to be VERY useful. Perhaps this is is the example you were looking for? Calling this tag useless is completely subjective. Much of what I see in other countries is full of useless tags. Mapping mailboxes and postal codes? No use to me, but very useful for people in another context and need. > and what is correct in a project like osm? correct name, all > attributes, the location. > correct location? accuracy +/- 1km, 1m, 1cm? This is the basis of ALL of OSM. Accuracy is up to the mapper, or collective mappers. All of OSM is dependent upon the good-faith efforts of mappers editing based on what they know and observe, to subjective standards that most reasonable people would hopefully consider "good enough", and then revise and improve over time. There is no absolute correctness which any of this data will EVER achieve. However good you think it is, somebody else will consider it inaccurate or incomplete. But reasonable people often can produce a consensus on a relative standard of "good enough for now", within a defined scope or context. For this, the tiger:reviewed tag works for many of us. > there are 2 solutions. delete > it on all ways as soon as data is downloaded to get rid of it or hack > the josm source. There is a completely valid third option you did not list: do like the rest of the planet. Completely delete the TIGER imported data in the area you surveyed. Start over from scratch with fresh GPS tracks and some Yahoo aerial photos. Of course, how will we know *that* is correct? Just because somebody claims it is? Hmm If you don't like the tag, you don't have to use it. But I have been waiting for this highlighting feature for a long time, but never got around to figuring out enough in JOSM, so I am happy to see it. To each his own; there is room for all of us in this project. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] GNIS Import
> There's a "copy tags" feature in JOSM that doesn't seem to work. That's > about the only way I know of right now. Pasting tags from node to way did not work for me, as recently as just a few weeks ago. However, I tried it just now on the current version 1515 and it worked. If there are tags on the way which you don't want to overwrite, just delete those tags from the node before copying. Not a good solution for the general case, but for the GNIS import, the node is just going to get deleted anyways. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] More USGS Geonames imports
> Do you mean Geonames as in the website (http://www.geonames.org) or is > Geonames a seperate USGS dataset with the same name? Good question. This a separate dataset which just happens to have the same name. It is a work of the USGS, unrelated to geonames.org. You can check it out at geonames.usgs.gov.Thanks - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] gnis:reviewed=no & map features
> if you can put the list of features along with the corrisponding OSM > tag to a wiki page, this would be helpful :) > (then i can help match features & cross-check to what i have) Unfortunately, in the case of my import for USGS Geonames items, they don't have specific feature categories. I'm doing subjective classification based on the names. In the source data, they are just classified as "building". So to be more specific about what I am doing, I will take a building named "Oregon State Police" and tag it with "amenity=police". Unless it is named "Oregon State Police Administration Building", in which case I will tag it with "amenity=public_building". So since I am not mapping discrete values, I don't think my list would be any more useful on a wiki page than the exising Map_Features page. FYI, although I'm calling this an import, mine is a semi-automated manual process. I'm doing this in a text editor on a file with one POI per line. I put in a value on each line for which tag I think it should have, which as I said is a manual guessing process. Lots of editor search-and-replace type stuff. I do have a little program to turn the text file into an osm xml file, but other than that, it is not really automated. I load the XML file into JOSM, validate, and upload from there. > i'm opting NOT to use the tag "geobase:reviewed=no" Your reasoning sounds good. I'm adding it to my load, because my tags are so subjective. I don't think the main USGS Geonames import needed it. Your plan should be fine, in my opinion. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] More USGS Geonames imports
I'm importing more points of interest from the USGS Geonames data. Many of the remaining places in Geonames are simply listed as buildings, with no particular type of place or use. They include libraries, museums, police and fire stations, etc. There is no specific classification in the data, leaving us to do it ourselves. I'm assigning values to them based on names. For example, if the place is named "Beaverton Public Library", it's easy to guess it should be tagged as "amenity=library". Some just don't have a specific classification on the Map_Features page (like office buildings or grange halls), so I'm giving them "building=yes". Some are unclear as to what they are, so they get "building=yes" also. Because of the subjectivity involved, I'm also tagging them with "gnis:reviewed=no", like Tiger. Many of them will require local knowledge to know the proper categorization, and positioning too. FYI, here are some example tags I am using for various names: tourism attraction Historic Site tourism museum Museum amenity library Library man_made water_works Pumping Station man_made works Heating Plant power station Powerplant amenity arts_centre Center For The Arts amenity bus_station Transit Center amenity courthouse Municipal Court amenity courthouse Courthouse amenity courthouse Court House amenity fire_station Fire Station amenity fire_station Fire and Rescue amenity doctors Healthcare amenity doctors Eye Care amenity doctors Chiropractic amenity kindergarten Child Care amenity kindergarten Day Care amenity parking Parking amenity parking Garage amenity police Police amenity police Sheriff amenity police Highway Patrol amenity prison Prison amenity prison Correctional Center amenity prison Correctional Facility amenity prison Penitentiary tourism information Visitor Center tourism information Welcome Center landuse military Armory landuse military National Guard amenity public_building County Building amenity public_building State Building amenity public_building Ranger Station amenity public_building Federal Building amenity public_building State Building amenity theatre Theater amenity theatre Auditorium amenity theatre Playhouse amenity townhall City Hall amenity townhall Town Hall shop books Book Store landuse residential Apartments leisure sports_centre Sports Complex leisure sports_centre Sports Center leisure sports_centre Athletic Complex leisure sports_centre Athletic Center leisure stadium Coliseum leisure stadium Arena and more :-) There are many combinations of names, so my tags are a basic start, not any authoritative answer. I'm going state-by-state in no particular order, and it will take a few days to finish. Please take a look around for areas you know, and fix up anything you find. Thanks. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Bridges, nodes, and routing engines (Navit, Gosmore, etc
> Now the question is: should I remove the shared nodes (or detach them > in JOSM), Yes, delete or detach. For editing simplicity, I detach them and at least move one a few feet away. In my region, the overpasses and bridges are usually misplaced or distorted, and need to be moved (or completely rebuilt) anyways. > fixed? My gut feeling is that the routing engines should be smarter > (basically, don't allow a route to change layers except at the ends of > OSM ways - in other words, you can't change from layer=0 to layer=1 by > turning off a way - in other words, any sane turn off a way not at its > end can't take you across layers,** and you can only "descend" or > "ascend" layers at the ends of OSM ways) but maybe this is a cleanup > that needs to be done in the data instead. That's a lot of assumptions in a lot of routing engines, for roads that just aren't connected at that node. I think we want the most useful data that can be readily used in as many different routing engines as possible, without a lot of obtuse rules and transformations. IMHO, If the roads don't really connect, don't share a node. > I've been reluctant to remove the nodes since we may need them to > match up other TIGER data (for example, the addressing data really > needs the tilds off the nodes to be able to figure out how to > associate addresses with the existing imported linework- the way tlids > alone are way too imprecise for this in many cases). Right now, I don't think keeping the nodes will make a big difference in retrofitting the TIGER addressing data. The TLID really applies to a Tiger line (way) section, not node, so the intersection nodes already have multiple TLIDs on them (some nodes have a dozen or more where long ways connect). And once the data got into OSM, ways started being split up and rejoined, without TLIDs being edited to match, so it is more of a hint than concrete identifier. What might really help for accurate addressing import is the Tiger TZID (a unique node identifier) on each node, but we didn't get that on our bulk load. I don't know if it is a more recent addition to the Tiger data or if we just didn't foresee it. Then again, it may not survive multiple edits any better. I would guess that in most of these situations, the bridge, overpass, or tunnel doesn't have any useful addressing that we need to salvage, so having the tiger-related node on the street level is probably fine. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Talk-us Digest, Vol 16, Issue 14
> Other discussion regarding the GNIS import suggests that the area is > preferred if available, and the tags (especially gnis:feature_id) should > be copied from the node to the area (and corrected where applicable.) Is there an easy way to copy the tags without retyping them? I can't seem to get the Potlatch repeat tags or the JOSM paste tags to copy from the node to the way. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Node versus area for school?
In my area I have some schools with both a node and an area. Most schools are just the node with the GNIS ID, but some have the school grounds mapped out as an area also. I see that both Mapnik and Osmarender will render the name of the area, as well as the node point. So the schools with both an area and a node have duplicate names on the map. Based on that, it seems like the node doesn't serve any purpose. I don't want to map for the renderers. I can imagine it might be useful to have the node for a POI list or other uses, even if I don't know specifically what that might be at the moment. My personal inclination is to keep both, and see if we can fix the rendering to label only one. Does anyone have any thoughts or opinions on best practices for the node versus area? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] GNIS Import Done
>>> 2. I'm planning on taking the planet dump and grepping out all of the >>> GNIS >>> data. This will be used to generate diffs that we can send back to the >>> GNIS >>> board, who has the option of putting it back into their data set. > Also, please report > anything you find. It would be great if the USGS had the wherewithall > to create an automated method to pull any changes out of OSM and back > into our databases. Well, I'm not planning on making a list of all my OSM edits to send back to GNIS, so I'm hoping the diff or other extract method works out. I'm finding errors and I'm just fixing them in OSM. I've been looking at schools and churches in the Portland and Seattle area. It didn't surprise me to find duplicates between GNIS-loaded nodes and previously-entered OSM nodes. The JOSM validator duplicate name detection and node merge make them easy to fix. If two identical names are within 0.0005 degrees of each other, they're probably a duplicate of the same item. However, it did surprise me to find quite a few duplicates within the GNIS data. For example, I found duplicate nodes for schools, with identical names, within a few hundred feet of each other, but each with its own GNIS ID number. Often there would be one node located right on top of the school building, and the other node on the street in front. (Looks like perhaps two datasets got loaded into GNIS, one perhaps geolocated by address? Who knows.) In the case of duplicated GNIS nodes, I've been keeping the one located on the building or school grounds, and deleting the one at the street. I hope the diff or extract method will be able to capture deletions like this and feed them back to GNIS. Right now, they probably know there are duplicates but don't know which one is correctly positioned. Our crack team of highly skilled OSM cartographers, as well as nerds like me, can help clean it up. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Court of Appeal Rejects Santa Clara County's Basemap Data Sale
>> One wonders what could be motivating the >> County to continue this very expensive resistance to complying with >> the PRA. Probably because Santa Clara is Silicon Valley, where a great amount of the local economy has been based on intellectual property law and issues. The past 20 years of software patents, digital rights management, and other such "innovations" are old habits (a century in Internet time) that are hard to break. Fortunately it is also full of equally innovative new efforts. Nice to see progress! - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger 2008 Data
> does the census bureau publish any sort of a "diff", or "delta" dataset? > i'd think that just in terms of raw crunching that having just the > differences from year to year would save a lot of work, both manual > and CPU-cycles. Not that I've seen. What they do publish is the TLID and TZID numbers in their data. These are permanent segment and node numbers which do not change from one Tiger release to the next, so you can do your own comparisons and updates. It also means that if you want to synchronize with them, you need to keep and maintain their TLID and TZID numbers. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excess TIGER nodes in a way
> Now the question. Should I 1) delete the (what I believe are) extra > TIGER nodes from the northbound way, 2) add a bunch of nodes to the > southbound way to make it match northbound, or 3) call it done and learn > to be happy? Choice 3 is always a legitimate option; if the map looks right then be satisfied :-) Choice 2, as such, is not worth doing unless you have a specific reason for making the ways match, more than just "they should match". The new nodes should serve a pupose, either in road shape, connectivity, or information. Choice 1 is the most likely candidate, although it may not be worth bothering with. The unasked question underneath this is: why would the TIGER way have more nodes than appears necessary? There are a few possibilities. The TIGER data is an amalgam of other sources, so the Census Bureau may have simply received it that way from the county, for example. TIGER also contains nodes for various purposes, indicating changes in street address ranges (not likely needed for freeways) or feature classes (sort of their version of our "highway" tag). Since we don't use all such various aspects of the original data, and we may not agree with the accuracy or classification of the original, then it is not important to us to keep a node-for-node match to the original. Since our current working stance is that TIGER was a one-time import and there are no working plans to try to maintain synchronization, feel free to edit it and "fold, spindle and mutilate" as you see fit :-) - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] intertwined ways in Austin TX
>> Does anyone with knowledge of the script have time to fix things in >> Austin? > > Yes, I will take care of it. Thanks for finding it. Well, that was interesting. There were about 200 braided streets in Austin that I found and fixed. They must really like the center island type of street. Let me know if you see any more. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] intertwined ways in Austin TX
> Does anyone with knowledge of the script have time to fix things in > Austin? Yes, I will take care of it. Thanks for finding it. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] Portland data
> In the US at least, I didn't think works paid for by the government could > have a restrictive copyright claim placed on them. In the US we have several levels of governments. Works created by the nation-wide federal government cannot be copyrighted. However, that does not apply to state, county, or city governments. They can copyright their works. Portland includes this statement: -- Copyright The City of Portland asserts ownership of its spatial data and all its portions. All title, ownership, and intellectual property rights which may exist or be created with the geospatial data shall remain with the City of Portland. The arrangement of facts of the geographic data, the organizational structure of the GIS databases, the coding of the GIS databases, the format of the GIS databases and the graphic design of its maps are the property of the City of Portland, as registered and protected by US copyright statutes and treaties. Recipients are restricted from displaying City spatial data on the public Internet without express written consent from the City. -- This can be found at http://www.portlandonline.com/omf/index.cfm?c=28144 in the data licensing documents. > Maybe this is data that a > company put together and then is licensing to the city? That is true in many situations. Portland mentions this in their data description, and says that data from commercial companies used by the City isn't even available from the City. The data that is available from the City is still copyrighted and restricted, as mentioned above. They have provisions for non-profit and educational use of the city GIS data at no cost, or low cost, but it does not include the right to redistribute the data. Too bad :-( - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
[Talk-us] Naming freeway exits and onramps?
In Oregon, freeway exits have official numbers ("Exit 3", "Exit 85", etc.)
I've been adding these as names to the motorway_link segments, thinking it
may be useful on the map as well as possible routing uses (Take Highway
217 to Exit 7 to 72nd Ave, etc.)
However, I think the name scheme as given only makes sense for the off
ramps. It doesn't really make sense for the onramps, even though they are
part of the same interchange.
Up to this point I have named the onramps with the same name, but I'm
wondering if I should use something else. I could leave them without a
name, or name them something else like "Highway 217 onramp" or "Entrance
7" or "Highway 217 onramp 7" or...
No signage is ever seen relating the Exit numbers to the onramps, but my
retentiveness wants to do something useful with all parts of the
interchange.
Anyone doing anything similar? Any thoughts or suggestions? Thanks.
- Alan
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] TIGER "unbraid" tool now available
>> i looked at some examples the last time this came up, and i've >> looked today, and i've read that wiki page, but for the life of >> me i can't figure out what's wrong with the streets that are >> referenced. Here is a good example (until somebody fixes it :-) http://www.openstreetmap.org/?lat=37.80259&lon=-122.42525&zoom=17&layers=B0FT I put a sample image on the wiki page, which can remain a stable reference as the various streets get fixed. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] TIGER "unbraid" tool now available
> i looked at some examples the last time this came up, and i've > looked today, and i've read that wiki page, but for the life of > me i can't figure out what's wrong with the streets that are > referenced. Actually, I may have fixed the best examples from that page while I was developing my script. I also deleted quite a few off the page; the list is only half as long as it was a week or two ago. I'll dig up a good example and post it. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] [OSM-talk] TIGER "unbraid" tool now available
> On Fri, 2008-04-25 at 13:42 -0700, Alan Millar wrote: >> You can find it at >> http://svn.openstreetmap.org/applications/utils/filter/osm-unbraid/osm-unbraid.pl >> >> Please give it a try and let me know how it works out. > > This is really cool! Thanks! > How were you envisioning this being run? Someone sees a braided street > (like in JOSM), saves the .osm file, runs the tool, then uploads? It does its own download so you just have to give it two way numbers, and it produces a JOSM change file. Then you open that in JOSM, check the results, and upload. I'm a little wary of automatic uploads. There are a number of intersecting ways listed on the Tiger fixup page that aren't really braided streets, and I'm not sure what it will do in all of those cases. > Could the algorithm be moved into the JOSM validator plugin? That might > make it quite a bit easier to edit things in fewer steps. I'd love to see it be a JOSM plugin; it would absolutely be easier to use. Select two ways, hit a button, voila! Unfortunately, it is in perl because that's what I know; I've never done anything in Java yet. I've been wondering if this may be just the time to learn it. I'm not sure if a JOSM plugin is a good place to start learning Java or if that is biting off too much to start. Any advice? Thanks - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
[Talk-us] TIGER "unbraid" tool now available
I have written a perl script which can fix a "braided" street in US TIGER data, as described at http://wiki.openstreetmap.org/index.php/TIGER_fixup It is a command-line tool which will download and fix the ways, and produce a file which you can open in JOSM to verify and upload. You can find it at http://svn.openstreetmap.org/applications/utils/filter/osm-unbraid/osm-unbraid.pl Please give it a try and let me know how it works out. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] Fwd: Maps of State of Wisconsin, USA
> It looks like a lot of useful information can be gleaned from this, > especially county, township, park, and municipality borders. > > I'm not sure if, or how, the maps could be used directly without some > sort of PDF overlay method in JOSM, or maybe a highly speciallized PDF > -> OSM converter. I haven't looked at the Wisconsin data, but I did do a little experimentation with PDFs. If the PDF contains a bitmap, you can extract it with any number of tools, but you're stuck with tracing. If it contains vector data, you can start to do intersting things. You can convert it to SVG using "pstoedit". I experimented a little using pstoedit to create svg, and then started on a perl script to convert the SVG to an OSM file for JOSM. It could be made to work for small areas where map projection would not be a problem. But because it is just line drawing data, you lose all original metadata about the lines. If some other GIS-type data is available, I'd try to use that first. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] braided streets
> On Mon, 2008-04-07 at 17:12 -0700, Alan Millar wrote: >> AFAIK Tiger doesn't have the concept of ways like we do; it just has >> the >> short segments. I expect that our script takes Tiger segments and >> assembles them into longer ways. In this case, it appears our script >> didn't know which segments went with which logical ways. > > Yes, that's exactly it. I tried to assemble the shorter TIGER segments > into longer ways. I wasn't horribly thorough about it. If the ways had > the same name, I combined them. This leads to some "interesting" street > sometimes, but it was a bit better than a couple million two-node > ways. :) Yes, that's for sure. I have been wondering about one thing, though. Have we lost something useful by not having the TIGER street address ranges? The ability to interpolate an address on a street seems pretty useful. Once the Tiger segments are combined into ways and the ways are edited or moved, it seems like we've lost the ability to go back and get the address info. Anyone else thought about this? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] braided streets
> The only thing I might do differently is not have the node shared > between the railway and the streets. That's what I did for the TIGER > upload: created two nodes at the same location. One for the street, one > for the railway. Oh, that was on purpose? Oops. JOSM validator complains about them, so I've been merging them where I find them. To me, it makes sense to combine them. If a car will have to drive over the tracks, then they should share the same node, it seems. I haven't really thought it through. How does it help to have them be separate nodes? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] braided streets
> so I see that braided streets are 'officially' a problem > > http://wiki.openstreetmap.org/index.php/TIGER_fixup Interesting. Looking at Google Street View, it looks like these are divided streets with an island or restriction running down the middle. It appears the Tiger data has separate segments for each side, with intersection nodes where there is a break in the island. AFAIK Tiger doesn't have the concept of ways like we do; it just has the short segments. I expect that our script takes Tiger segments and assembles them into longer ways. In this case, it appears our script didn't know which segments went with which logical ways. > anyone have a good way of fixing them? I'm happy to have a go in SF. With 165 streets like that listed on the wiki, I wouldn't want to edit them by hand myself. And those listed are just in SF. I suspect the problem may exist elsewhere also. I think deleting them and re-uploading them with the script might be worthwhile, if there could be some more discrimination or constraints. I could see it being tricky, though. I can imagine a script that goes through the two ways and identifies the average angle of the street, and swaps node membership in the ways to match which side it should be on. Perhaps Dave Hansen has some insight on the Tiger upload script. Another question is what do we want to do with the intersections? Should it be a single node, or two nodes? I just dealt with this at: http://informationfreeway.org/?lat=45.553593680216935&lon=-122.68115036884754&zoom=17&layers=B000F000F In this case it is a split street with light rail tracks down the middle. I made it three nodes where the two directions of the street and the tracks cross the perpendicular street. Although logically it is one intersection, I think it looks better on the map this way. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
[Talk-us] Better urban WMS layers for JOSM
I've been trying to find some easier ways to clean up the Tiger data for my area around Portland, Oregon. I've been corresponding with a few others also trying to do the same thing. I'll skip to the punchline first: Better JOSM layers for aerial photos at http://terraservice.net/ogcmap.ashx?version=1.1.1&request=GetMap&Layers=urbanarea&Styles=&SRS=EPSG:4326&format=image/jpeg&; and public street maps from the county tax office at http://columbo.nrlssc.navy.mil/ogcwms/servlet/WMSServlet/Portland_OR_Metro_Maps.wms?VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=0:42&FORMAT=image/png Here's the long version of the story: For my county, I've found excellent position consistency among all data sources other than Tiger. My GPS readings match the Yahoo aerial photos, Google Earth, Washington County tax maps, Beaverton city maps, and the USGS urban area photo maps at terraservice.net. The Tiger data is broadly correct with pretty much all the right streets in the right relationships, but it is often shifted out of place by varying amounts. So everybody agrees except Tiger. This is good, in that it gives me confidence in the other sources, meaning I don't have to travel every single street with my GPS since my tax dollars already did so. I figure that if I get a large rectangle by GPS which matches the aerial photos, then the area within the rectangle can be aligned with just the photo. I've been looking for the most efficient way to do that. Sometimes the Yahoo aerial photos are not as clear as I would like, such as being obscured by trees. Although I like the simplicity of Potlatch, I found I really need the multiple-node selection and movement capability in JOSM for realigning the Tiger data. The key, then, has been to find better sources of public data which I can use as WMS layers in JOSM. The first was better aerial photos. I don't copy from Google Maps or Earth, but I do occasionally cross-check things there. I noticed in Google Earth that the on-screen credits do change, and seem to reflect the actual source of your current view. I found Portland, OR credited for close-up aerial street photos. Digging around some more, I found that this data is being distributed by the USGS as part of its urban area focus project, and I stumbled into this page: http://wiki.openstreetmap.org/index.php/User:Beej71 showing how to use it as a WMS layer in JOSM. Item number one (better photos) solved. Item number two took longer to figure out. I've used the Washington County tax maps at http://washims.co.washington.or.us for several years for personal use, before I found OSM. I have seen references on the county web site to ESRI and ARC software, so I knew there was a decent base underneath. The one thing I could not find was any WMS services. I spent some time with PDF maps, and hit a dead-end with MetaCarta's currently-broken map rectifier :-( This sent me hunting again back closer to the source. I eventually Googled into a Navy project which is a WMS server for many GIS sources, at http://columbo.nrlssc.navy.mil/ogcwms/servlet/WMSServlet With some WMS experimentation in Google Earth, I was able to find what I was seeking: decent street maps from the county tax assessor at varying levels of resolution. Quite excellent resolution, in fact; the details increase as you zoom in closer to the street and lot level. Problem two solved. Although I'm focusing on one particular county, it appears that the Navy project has hundreds or thousands of data sources available. If your county data is there, it may be worth a look. I understand that we need to be very cautious about copying other people's intellectual property into OSM. In this case, since the data is based on public records from my tax assessor's office, I don't expect there is a problem in using it as a verification base for the Tiger data. The only minor problem I am having is that the Portland tax maps have light grey lines on a white background for the streets, and the mappaint mode in JOSM is hard to see on top of it. Switching to wireframe mode is an adequate workaround for now. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
