Re: [Talk-us] How accurate is Tiger data vs Yahoo Aerial?
On Fri, 2008-02-22 at 12:23 -0800, [EMAIL PROTECTED] wrote: Hi- I've just joined up and I'd like to help out cleaning up the map for my area in Beaverton/Portland Oregon. It looks like it is completely covered already by the Tiger data. But I've noticed many displacement problems where the Tiger data doesn't line up with the Yahoo aerial photos. Hey!! Another Portland mapper!! I see the same displacement of the TIGER data. Some of it is really bad. Cornell road out by my house: http://www.informationfreeway.org/index.php?lat=45.53651932780694lon=-122.89710601634569zoom=15layers=F0B0F was about 100 yards off, and *RIGHT* on top of another road. It was really confusing to look at those traces. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] highway tags in the US
On Thu, 2008-02-28 at 20:18 -0600, Ian Dees wrote: I have a hard time deciding which value to use based on the UK-centric descriptions on the wiki. They're not hard and fast rules, honestly. You also can't completely say all (US/State/County) highways are primary/secondary/tertiary, etc... For instance, OR217 and US26 west of Portland are both divided, multi-lane, limited access highways. Despite not being interstates, they *ARE* motorways. As for primary/secondary/tertiary. I basically think that primaries are those really big roads that happen once every mile or two. They're the ones where WalMart is. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] highway tags in the US
On Fri, 2008-02-29 at 11:02 -0600, Alex Mauer wrote: Dave Hansen wrote: For instance, OR217 and US26 west of Portland are both divided, multi-lane, limited access highways. Despite not being interstates, they *ARE* motorways. Hmm, are you sure? maybe they just look like motorways; there are a lot of almost-motorway roads I'm pretty sure I know one when I see one these days. http://wiki.openstreetmap.org/index.php/Map_Features A restricted access major divided highway, normally with 2 or more running lanes plus emergency hard shoulder. Equivalent to the Freeway, Autobahn etc.. Bingo. It's truly restricted access. No access except from onramps. It's divided. It also has emergency shoulders. Is is effectively an interstate. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] highway tags in the US
On Mon, 2008-03-03 at 19:36 -0600, Alex Mauer wrote: Dave Hansen wrote: I'm pretty sure I know one when I see one these days. http://wiki.openstreetmap.org/index.php/Map_Features A restricted access major divided highway, normally with 2 or more running lanes plus emergency hard shoulder. Equivalent to the Freeway, Autobahn etc.. Bingo. It's truly restricted access. No access except from onramps. It's divided. It also has emergency shoulders. Is is effectively an interstate. There are many roads that fit those definitions, but have, for example, too-sharp curves, too-low bridges, perhaps too-narrow shoulders, etc. to meet the legal definition of an interstate. Of course, it's very possible that they've simply not been designated as Interstate, but my point is that it's not easy to tell at a glance. Yep, you're probably right. So, go submit a proposal and get the motorway definition changed. Right now, I'm following it to the letter. It doesn't matter that motorway!=interstate. It's easy to tell an interstate from its name anyway. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] highway tags in the US
On Mon, 2008-03-03 at 23:23 -0500, Bone Killian wrote: certainly a highway that meets the standards without being designated should be tagged as motorway, but as IMHO the only thing that qualifies a road as a motorway (in the US) is the big red and blue signage identifying it as part of the interstate highway system. Have you actually read the highway definition on the map features page? http://wiki.openstreetmap.org/index.php/Map_Features It has zero to do with shiny red signs. :) In fact, there are even stretches of interstate in this country which aren't technically motorways. http://en.wikipedia.org/wiki/Interstate_93 : I-93 passes through Franconia Notch State Park as a Super-2 parkway, the only instance of a two-lane Interstate highway in the United States. This stretch carries a 45 mile per hour speed limit. For the trip through Franconia Notch, I-93 and U.S. Route 3 run concurrently. -- Dave ___ 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 14:46 -0700, Alan Millar wrote:
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
Thankfully, the validator tests don't require *too* much java. You can
basically cut 'n paste from an existing one with very little trouble.
I hadn't touched Java in about 10 years before I started looking at
JOSM. I do a lot of C on a daily basis, but no Java. It wasn't hard to
pick back up.
Here's an example validator test:
http://svn.openstreetmap.org/applications/editors/josm/plugins/validator/src/org/openstreetmap/josm/plugins/validator/tests/DuplicateNode.java
You basically examine all the Osm Primitives in a couple of visit
functions like this:
@Override
public void visit(Node n)
{
nodes.add(n.coor, n);
}
Usually, you just collect them into a structure like that 'nodes' list.
Then, in the endTest() function you go an examine all of them. I've
been keeping custom versions of JOSM around that have some really nice
helpers for writing JOSM plugins.
http://dev.openstreetmap.org/~daveh/josm/018/
Like this:
for (Way wtmp : Main.ds.rl.waysUsingNode(n)) {
That iterates over a list of all the ways using Node 'n'. You probably
recognize this operation. I think you do it a bit in your perl script.
-- Dave
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] US Hydrographic Data
On Thu, 2008-05-01 at 10:17 -0700, Karl Newman wrote: That would be awesome. Maybe we could rip out the TIGER hydrographic features and replace them with the NHD stuff. Maybe coastlines, too? I guess we'd have to be careful about duplicating/overwriting people's work, though. Uh. There are no TIGER hydrographic features in OSM. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] US Hydrographic Data
On Wed, 2008-05-07 at 10:51 -0500, Ian Dees wrote: I was going to modify Matthew's script here: http://perrygeo.googlecode.com/svn/trunk/gis-bin/nhd_to_osm.py to try and fix the issues that he described in the header: - support holes in water bodies (islands) - tag OSM data with all available NHD data - split long ways in the resulting OSM data Dave, maybe you could point us to the script you used to import the TIGER data? That way we can try and do a similar thing for the NHD data? It was written in ruby. I inherited most of it from someone else. I think ruby sucked. :) http://sr71.net/~dave/osm/tiger/ -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] bulk upload of data to OSM: roads, water, and orthos
On Wed, 2008-06-25 at 12:42 -0400, John Callahan wrote: Spatially it's no contest. I've attached just a few simple images to show what I mean. These show our new dataset in red vs TIGER 2007 in purple. Remember that the red lines match the hi-res photography. Wow. Hard to argue with that! It does look great. Attributes are also an improvement for geocoding, routing, and naming. True. We do have addresses in the TIGER data, but I chose not to upload them for now. OSM didn't have relations when I was doing the original TIGER upload, and I'm still not sure there is any consensus on how to do address data. Probably good to bring up on dev@ or [EMAIL PROTECTED] Good question about contacting OSM editors of this data. I can easily contact most of the GIS data professionals and govt'/consultant/University people who typically with transportation data. However, that does leave out the single individual, say at home, who modifies the data. Not sure how often that happens. I can always keep an copy of the current OSM data before uploading the new data set and replace parts of needed. Or is there a way to find any edits made since the intial loading of the TIGER? My suggestion would be to get a planet file, and try to extract the areas that you care about. http://wiki.openstreetmap.org/index.php/Planet.osm You could just about download the entire thing in JOSM, too. It's a pretty dinky^Wmodestly sized state. ;) Once you have a copy of the existing .osm data, just grep through the XML to look for authors, or look at the authors panel in JOSM. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] Adding Public Domain GIS data from Allegheny County (Pittsburgh) Pa
On Mon, 2008-07-07 at 16:10 -0400, Morgan Ress wrote: * High School Students that are working here for the summer, in a program designed to teach them about GIS and community planning. Currently, they are working on detailed maps of our neighborhood using QGIS - I'd like to make our work available to our community via OSM. Just curious, but what kind of data is this? We have some road data from TIGER, already. What would this add? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] Portland data
On Wed, 2008-07-16 at 07:57 +0100, SteveC wrote: Can anyone (especially anyone local to Portand but it's not crucial) take some time to look and see? Adam says: I called Metro today, and they say their data is not public domain, so I think that makes it unusable on OSM. Oh well. Adam :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] TIGER 2007 files
On Thu, 2008-07-17 at 21:10 +, [EMAIL PROTECTED] wrote: Is the Census Bureau going to continue to make regular (ie. annual or semi-annual) data releases of street centerline data, or does the 2007 TIGER/Line Shapefile release represent the end of the project? I can't imagine this will be their last release. I'm sure they'll continuei If they plan on releasing incremental updates, is there an OSM plan in place for pulling from their updated information each time they release? or was the 2006 data intended to be a baseline that would then be improved and maintained only by OSM users? It was a real pain to import one static data set onto a blank slate. I can't even imagine trying to: 1. Read the new features 2. Find out what those were mapped as in 2006 when we pulled the TIGER data 3. Figure out where those features went in OSM 4. Figure out if those features have been updated 5. Which copy is better 6. Update those features in a safe manner and at a speed that would allow us to complete by the time the next data set is out. Seriously, I always saw TIGER as a one-time thing. If someone is really interested in doing this, I don't want to stop them. But, as the dude who did a pretty big chunk of the work for the original import, I can say that I don't really even have the time to begin on this one. :) What we might be able to do is find holes in the original data and see if those holes have been filled in. That might be a reasonably simple place to start if someone is interested. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] using city data?
On Wed, 2008-08-20 at 17:36 -0700, Alan Brown wrote: I think this is a case of where, if I get clarification from them further, it *might* be okay, but the wording is too fraught with ambiguity to be safe. Here's the part I'm worried about - I explained in an e-mail what OpenStreetMap is about, they said sure!, sign this and we'll get it to you for free - and sent me this: Oh, boy! :) Personally, I'd probably want a lawyer to look at it. Mostly to make sure that what you've given the city to describe OpenStreetmap is in legal terms and done very tightly, legally speaking. *Especially* with political organizations, their loyalties can turn in 4 seconds. I wonder if OSM has any friendly attorneys like other Free Software communities do. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Tiger 2007 Data
Has anyone looked at importing the TIGER 2007 data yet? I was going to start coding up the conversion utilities to get started. It appears that this shapefile format may have existing OSM converters out there. Anyone want to admit to having one? ;) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger 2007 Data
On Sun, 2008-10-19 at 11:33 -0700, Alan Brown wrote: Then, decide how if/when it is appropriate to write over the old TIGER stuff with new. Or, to merge it somehow. Be very, very careful here. Conflation is a difficult thing. I used to work at Tele Atlas, and there was a major project to conflate Tele Atlas North American data and GDT data (a company they just acquired). They had at least a hundred people committed full time to completing the task in a year (I don't know the exact number), with tens of millions in funding - and they failed in a big way. The head of the North American division got axed as a result. It's not a difficult thing if nothing has been changed since the last import. My goal for now is simply to overwrite the things that haven't been updated by people since the last time I touched them. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] TIGER 2007, first OSM data
I'm trying to share early and often. :) Here's the first output from my new TIGER 2007 script. I used shp2osm.pl from SVN and added a perl port of a chunk of the ruby code from the original TIGER import. http://dev.openstreetmap.org/~daveh/tiger/2007/OR-Sherman.osm.bz2 This doesn't have any of the right OSM tags, but it *is* data of some kind and opens in JOSM. Here's the code that I used: http://dev.openstreetmap.org/~daveh/tiger/2007/tiger2007-tools-001.tar.gz You can run it like this: perl tiger-shp-to-osm.pl data/ftp2.census.gov/geo/tiger/TIGER2007FE/41_OREGON/41055_Sherman/fe_2007_41055_edges.zip out-dave.osm Don't count on any more tarball releases. I think I'll just stick it in a git repo and forget about it. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER 2007, first OSM data
On Tue, 2008-10-21 at 22:58 -0500, Chris Lawrence wrote: On Mon, Oct 20, 2008 at 8:16 PM, Dave Hansen [EMAIL PROTECTED] wrote: You can run it like this: perl tiger-shp-to-osm.pl data/ftp2.census.gov/geo/tiger/TIGER2007FE/41_OREGON/41055_Sherman/fe_2007_41055_edges.zip out-dave.osm Don't count on any more tarball releases. I think I'll just stick it in a git repo and forget about it. Dave - Thanks! A couple of small problems so far: - The tarball doesn't include daveperl.pm; I found it elsewhere on your site. - Latitude and longitude seem to be reversed in the output, at least when I use the data for Webb County, Texas (FIPS 48479) as the input. This *really* confuses JOSM (e.g. it hangs). Heh, I noticed that too once I ran it on my county. I think you're the only other one to notice. :) I fixed this problem using: sed -e 's/lat=/xxx=/g' -e 's/lon=/lat=/g' -e 's/xxx=/lon=/' TX-webb.osm | TX-webb-fixed.osm As the accuracy improvement project hasn't affected this area yet, the shapefiles aren't any improvement over the existing data (and are worse than the manual edits a few of us have made), but hopefully the effort will be worthwhile elsewhere! If you know of another county that has had improvements that you want to check, let me know. I'll run it on any new counties, too. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger 2007 Data
On Fri, 2008-10-24 at 22:09 +1100, Nick Hocking wrote: Can you confirm that any bulk upload of Tiger 2007 date will not erase or be overlaid over/under/alongside any existing user edits. On my last US trip I've got about 6000 miles of gps tracks. I've only edited in a few hundred miles of them so far but am reluctant to do any more work if the Tiger 2007 data will destroy what I've done so far. Dude. Chill. :) I don't know what's going to happen. I don't even really have working data to look at, yet. Let's say there's a county with a single node set to reviewed=yes. the rest of the 4 million nodes in the county aren't set as reviewed. That county has much improved TIGER data. Should we leave it alone? What about 10 nodes? 100? We need to answer those questions at some point. Personally I don't really care where we draw the line. Destroying (or corrupting) existing edits would nullify the current efforts by Cloudmade to enhance a US community (IMHO). Again, let's calm down a little bit. Were you around for the last import? Did you see how I handled data conflicts in that one? Was there a problem there that needs fixing this time around? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger 2007 data
On Sat, 2008-10-25 at 10:37 +1100, Nick Hocking wrote: I'm firmly convinced that automatic uploads should only go into areas where there are NO user edited nodes or ways. Other updates need to be done manully to avoid data corruption. You have absolutely shown a number of cases where there was no merging and the TIGER data was simply splatted over existing data. This is certainly one of the downsides of the approach that was tried before. I uploaded Oregon first because I had already talked to all the mappers in my own state. I then proceeded to upload all the states that were completely empty. After that, I used this map: http://ted.mielczarek.org/code/osm/counties/ and uploaded only counties that were virtually empty. Interestingly, people started contacting me pretty quickly saying you missed my county! That's because the areas with the most data were also the places with the most active mappers! Almost all the prolific mappers knew that they could never compete with the pure amount of TIGER data and went to the heroic effort of merging their existing work with it. In the end, I think there was only a single county (out of ~3000) in the US that didn't get TIGER data in one way shape or form, and I gave people plenty of time to decline. So, I completely disagree that the merging can and should be done manually. There's simply too much data. It's also not feasible to blacklist every county that has *ever* had a single edit. But, I don't want to corrupt anything. Just as before, I'm going to let all the decisions be made by the local mappers. If you're concerned, please stay on this list because I'll always announce things here (at least). -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tiger Data 2007
On Tue, 2008-10-28 at 15:46 -0700, Alan Brown wrote: If those 10% are located where someone has poured their heart into making a carefully constructed map - you could disillusion some of your most active contributors. Yup, I completely agree. But, one of the nice things is that the active contributors are the ones that tend to read mailing lists and see the OSM site regularly. They should be the easiest to contact and be the most flexible about finding the best ways to get this data imported. If somebody owns 95% of the edits in a county, I don't really *ever* think it is OK to overrule them, certainly not in some automated way. But, we surely have to distinguish those users from the ones that popped up, moved one road in potlach to match Yahoo, and were never heard from again. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER 2008 Data is Out
On Thu, 2008-12-25 at 23:22 +1100, Justin Adler wrote: Hi folks, quick question about this Tiger lines and OSM. 1) Are there any import scripts out there which are not rails or php? something in .NET maybe? No. 2) Do the tiger lines have the following data (which could then be imported into OSM) : a) State shapes (eg. California, New York (state), Illinois, etc) b) County shapes (eg. Cook County (IL), DuPage County (IL) etc) c) City shapes (eg. San Fran, Boston, Chicago, etc.) d) Suburbs (eg. Oak Brook (Chicago), Naperville (Chicago), etc) e) Neighbourhoods (eg. Tribeca (NYC), Chelsea (NYC) Yes. 3) Does OSM have this data? Yes. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tags for US Forest Service GIS Trail Data
On Thu, 2009-03-05 at 10:48 -0500, Russ Nelson wrote: Also, are there tags to keep information about metadata like the data source (i.e. gps, digitized, etc)? Chris and Dave have set a standard for imports that says that existing metadata should be preserved. As long as you do that, anybody who comes along later can turn that metadata into OSM tags. Yeah, I'd say please preserve as much as you can *especially* so people can track the origin of the data. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tags for US Forest Service GIS Trail Data
On Thu, 2009-03-05 at 08:11 -0800, Matt Maxon wrote: Here in SoCal parking most anywhere with in a National Forest requires paying a fee $5 daily or $30 annual ($80 Public Lands pass too) Same basic system in Oregon and Washington. Some trailheads are special, usually when they're really busy for some reason. There are also entry requirements for some trails. For instance, each group needs to have a filled-out form when entering a national forest around here. Groups are also limited to 12 heartbeats. That stuff is good to capture in some way. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Duplicate TIGER imports
On Tue, 2009-04-14 at 15:41 -0700, Minh Nguyen wrote: A few weeks after DaveHansen imported the TIGER data for Ohio [1], RSatterf reimported the data for Greene County, Ohio [2]. As a result, every single way in the county is duplicated. On top of that, RSatterf's import also added a loose node (not connected to any way) for every node of every way in the county. Here's an example at the Montgomery–Greene county line [3]. It's a real mess, and it looks like we just need to delete every node or way last edited by RSatterf. We should keep ways that've been edited by another user since then, because in some cases DaveHansen's motorways etc. have probably been deleted in favor of RSatterf's. So does anyone have a handy mass deletion script? Urg. That's too bad. Actually, on the counties that I screwed up on and had to remove and re-apply, I just did it with pieces in JOSM I think. The scripts that I do have to do it are pretty tied to the BerkeleyDB format that I used for my cache. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Duplicate TIGER imports
On Tue, 2009-04-14 at 19:22 -0500, Chris Lawrence wrote: On Tue, Apr 14, 2009 at 5:41 PM, Minh Nguyen m...@1ec5.org wrote: A few weeks after DaveHansen imported the TIGER data for Ohio [1], RSatterf reimported the data for Greene County, Ohio [2]. As a result, every single way in the county is duplicated. On top of that, RSatterf's import also added a loose node (not connected to any way) for every node of every way in the county. Here's an example at the Montgomery–Greene county line [3]. It's a real mess, and it looks like we just need to delete every node or way last edited by RSatterf. We should keep ways that've been edited by another user since then, because in some cases DaveHansen's motorways etc. have probably been deleted in favor of RSatterf's. So does anyone have a handy mass deletion script? It probably wouldn't be too hard to whip up something that uses the extended API to query the database and generate an OSM XML file you could churn through using the bulk uploader script (probably just an XSLT transform of the returned XML would do it). The only issue is that you might have some shared nodes that are in-use by ways that you don't want to delete. I used the xapi interface and I'm already running through them to clean out the duplicates. Minh, I seee 27 standalone nodes of yours that you've fixed up. Do you mind if we just delete these? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Blame me for JOSM yellowness
On Fri, 2009-04-24 at 09:40 -0700, Alan Millar wrote: 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. 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. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Blame me for JOSM yellowness
On Fri, 2009-04-24 at 10:26 -0700, Apollinaris Schoell wrote: forcing every josm user to accept it is somewhere between ignorance and dictatorship Hi Apollinaris, I'd be happy to code up a custom version of JOSM for you that doesn't have the yellowness. I'd also be happy to looking into making it a persistent option so you can turn it off once in your preferences and never worry about it again. I can't guarantee anything about the base version of JOSM, but I can certainly customize it and share whatever I do with you. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tool to fix Tiger data
On Fri, 2009-05-01 at 08:32 -0700, Apollinaris Schoell wrote: this one is way more useful than maplint. but it's europe only at the moment Anyone with plans to provide a US version? Tiger doesn't have directions on (some?) motorways, motorway_link and may of them are wrong. this service can flag dead ends. http://keepright.ipax.at Ugh. Those are all written in sql. :( I've been using the JOSM validator plugin to fix this stuff on a small scale. I've had dreams of using the same code to do fixing of TIGER stuff outside of JOSM, but haven't ever gotten around to it. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Blame me for JOSM yellowness
On Mon, 2009-04-27 at 09:50 -0700, Apollinaris Schoell wrote: tiger data is that the quality is from excellent to really bad in accuracy tiger data is old and contains abandoned roads tiger has no level info, no direction for oneways, no turn restrictions, or any other fancy info which we add in osm all this requires rework for most freeways, but it is good enough for lot of residential areas. As others pointed out the reviewed tag is too crude to mean anything we can all agree on. My personal view on TIGER is that it is like GPS tracks on steroids. GPS tracks are an excellent source of mapping data to help build OSM. They have good information about where roads are, what their shapes are, etc... But they generally can't tell you about an intersection's layout, turn restrictions or other surface features. But, they can't be relied upon universally. People have bad GPSes, they also forget to turn off their lock to road feature, etc... TIGER is a wonderful skeleton on which to build but it along is not a complete or *good* map. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER Data in Wrong Place
On Wed, 2009-05-06 at 19:08 +0100, Andrew Ayre wrote: Hi! When I load OSM data into my GPS unit using mkgmap for a place in the UK then it is accurate. When I load OSM data for Tucson, Arizona then it is off by perhaps 100ft. I would like to make the maps for Tucson usable, so my questions are: - how do I tell where this problem begins and ends? You probably can't do this on a large scale. - how do I fix it? In JOSM, you can select and move large numbers of objects at once. My neighborhood was off by a couple hundred meters. I went and fixed it all back up manually. I don't have the time to manually move everything, so there must be some kind of automated solution? Does this problem exist for the whole of the US? Is it well understood? No, it doesn't exist for the whole US. It is well understood. TIGER is a collection of data from many, many sources. Some of these were from local governments that were themselves aggregating data from multiple sources. Sometimes, the data were off from one of these sources. It was not collected for the sole purpose of mapping, so nobody really cared. Also if you look at the diagonal (NW-SE) part of the Arizona-Mexico border there are streets in the US that appear in Mexico - the whole border area appears to be a mess. How do I know what needs to be done to fix this? The error looks larger than 100ft. You really need some good GPS traces of the streets, or you can try to align it on yahoo imagery. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tidying up TIGER data
On Thu, 2009-06-04 at 00:36 -0600, Ted Percival wrote: Its functions are: - Strip St suffix from grid-named streets (eg. South 500 West) - Collapse multiple spaces into a single space (lots of TIGER) - Expand abbreviated directions (eg. S 500 E to South 500 East) - Expand abbreviated suffixes (Rd - Road, St - Street, etc) So, I looked at doing this when I originally converted the TIGER data. The issue is that I'm too dumb to come up with anything that worked universally across the entire country. This kind of script is useful for small areas that you've looked at manually, but please don't apply it too widely. It does the right actions for sanely-named things, but TIGER is full of goofy stuff. Consider: St. Helens St.. There are also plenty of semi-mistakes or weird abbreviations in TIGER that appear to be mistakes. I wouldn't be surprised to see Saint Street entered somewhere as name: St. type: St. We don't want to make that Street Street. That makes it even worse. :) Again, these can work in limited areas where the naming is nice and consistent, but it's really really hard to make it work on a large scale where things are *NOT* consistent. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Strange synthentic GPS tracks spelling out words
We had a super-cool mapping party in Portland, OR this weekend. But I noticed some really werid GPS traces. Somebody has spelled out things like ATM and SUSHILAND in the GPS tracks, and they weren't walking around spelling things. ;) Take a look around 45.524613, -122.694281. I'm just curious who uploaded these. They seem pretty harmless and kinda funny, but I wonder why someone would go to this trouble. Or did someone's GPS automatically translate waypoints into these things? Any ideas? -- Dave atm.gpx Description: XML document ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing Alignments in JOSM
On Tue, 2009-06-23 at 11:57 -0700, Andrew Ayre wrote: So I need to split the North-South way into two pieces and it intersects the East-West way in two places. I cannot figure out how to do this in JOSM. I've tried everything - splitting a way at nodes, ungluing, etc. The way always remains joined. Can someone please give me a step by step guide to fixing this alignment problem? Sounds like a fun intersection. :) Could you give us some coordinates for it? I'll go take a look and see if I can explain what best to do. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER
On Tue, 2009-07-07 at 10:23 -0700, Apollinaris Schoell wrote: it's bad if you don't have a 4WD but your navi thinks it's perfect to use :( but even tomtom, google, ... have the same errors in these areas. if we want osm to be better there is no easy way to get it right without checking the reality. mass imports give a good starting point but it's really hard to remove the old invalid data and there not many mappers in remote areas to verify it. Amen to that! If I had it to do all over again, I'd make a unique user-id for each upload instance. The upload-uuid helps, but it's not volatile upon edits. It would probably be smart for any navigation system using OSM to check for tiger:reviewed=no. Perhaps I should go thorough and retag the TIGER data which is so far been unmodified. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER corrections
On Wed, 2009-07-08 at 17:55 -0700, Dave Hansen wrote: On Wed, 2009-07-08 at 17:08 -0700, Alan Mintz wrote: 1. Short road N Laurel Ave (way 7497408) ending at a T-intersection into W 18th St (way 7516644). TLID is 144674357. The node at the T has TLIDs 144674357:144674376:144986081, which is fine - the two segments of W 18th St that join the T are 376 and 081. However, the node at the south (dead) end of the road has the same TLIDs (144674357:144674376:144986081) instead of just 357. It looks like you found a genuine bug in the way I stored the tlids. Lemme see if I can track it down and figure out how to work around it. Man, this was a crappy bug. Basically I used a reference when I should have used a copy of each node's tags. This causes all nodes that are created as part of a feature to share a copy of tags. Any nodes that were created as part of older features will have the new tags merged into them. But *all* of the nodes that were part of the older feature are inadvertently modified. Urg. It *is* fixable to some degree. I can re-run the generation scripts and remove the superfluous TLIDs from the nodes. But, that's going to be quite a bit of work. I probably need to think about better solutions than that. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed automated motorway_link mass edit
On Fri, 2009-07-17 at 03:41 +0200, Frederik Ramm wrote: Preliminary analysis shows that there would be roughly 28k changes across the whole US. I have prepared a full list of all proposed changes, arranged by state and county, here: http://www.remote.org/frederik/tmp/us-motorway-link-downgrade/ Frederik, that's exceedingly cool stuff. I have a validator plugin test to do this which I was testing last weekend, but yours is on a completely different scale. Notice the lack of edits in Washington, county, OR :). Yours is very nice work. Can you share some of the scripts and methods you used for this? I do think that some automated fix-bots would be nice to have run periodically for cleanups like this that are pretty easy to verify. I'd also like to look into some gluing back together of the TIGER counties and I wonder how suitable this would be. Again, very, very cool stuff. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed automated motorway_link mass edit
On Fri, 2009-07-17 at 15:46 +0200, Frederik Ramm wrote: This brings down the number of proposed changes from 28k to 26k. The new list is at the same place: http://www.remote.org/frederik/tmp/us-motorway-link-downgrade/ Some of these at least are from a botched TIGER county that I screwed up during the upload in Lane county. It's probably another good example why that we should stay far far away from these in the automatic downgrade. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed automated motorway_link mass edit
On Fri, 2009-07-17 at 08:10 -0700, Russ Nelson wrote: On Jul 17, 2009, at 2:24 AM, Frederik Ramm wrote: I'd also like to look into some gluing back together of the TIGER counties and I wonder how suitable this would be. My gut feeling is that this calls for a semi-automated process in which a script suggests certain changes but humans still have to confirm them individually. This will be technically possible when third-party web applications can make API changes in the name of others by using OAuth (soon to be deployed on osm.org). Not something you'll write over a weekend that's for sure! Some of it can definitely be automated. If you have a way that stops at a node, and there is another node at the same location attached to a different way, the nodes should be merged. Well, with appropriate checks of course. We wouldn't want to do this with interstates and regular roads, power lines or other incompatible ways. But I agree in general. Another fix I'd like to see is to look at all the Interstate Highways, and if there is a road connected to it at any angle between 45 and -45, disconnect it. An even more aggressive fix would be to disconnect everything that isn't a motorway_link. That's probably correct, but more aggressive than I would choose to implement. Yep. I've even got a JOSM validator plugin test to check motorway intersections. It doesn't do the angles, but just ensures motorways only touch other way types at their endpoints. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed automated motorway_link mass edit
On Fri, 2009-07-17 at 10:27 -0500, David Lynch wrote: On Fri, Jul 17, 2009 at 10:10, Russ Nelsonr...@cloudmade.com wrote: An even more aggressive fix would be to disconnect everything that isn't a motorway_link. That's probably correct, but more aggressive than I would choose to implement. Not a good idea at all, IMO. I can think of numerous places within 50 miles of my home where, due to existing highways being upgraded to motorway or towns being bypassed by freeway/motorway-grade highway, there are nodes which have both motorway and non-motorway ways connected, because the motorway lanes empty directly onto the old highway Yeah, you definitely have to be careful. It's OK for a motorway to touch: 1. another motorway 2. a motorway_link 3. a non-mototorway, but only at its *END* node. Not at its beginning node 4. service roads. Our friendly police officers love to use these little spurs to hide for speed traps in Oregon. :) Here's where I-72 ends, for instance. This really is a full motorway and I wouldn't call it a motorway_link even up until the point where it runs into a stoplight: http://www.openstreetmap.org/?lat=40.12193lon=-88.28141zoom=15layers=B000FTF -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed automated motorway_link mass edit
On Fri, 2009-07-17 at 09:19 -0700, Apollinaris Schoell wrote: Yep. I've even got a JOSM validator plugin test to check motorway intersections. It doesn't do the angles, but just ensures motorways only touch other way types at their endpoints. very useful, can you share? Here are my current jars: http://sr71.net/~dave/osm/josm/07172009/ The problem is that I need a few core changes in JOSM. I got a few of them upstream, but I need my ReverseLookup code integrated. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposed automated motorway_link mass edit
On Fri, 2009-07-17 at 10:35 -0700, Russ Nelson wrote: On Jul 17, 2009, at 9:29 AM, David Lynch wrote: Because I and numerous other mappers have put a hell of a lot of time and effort into getting things right, and I don't want anyone breaking it because an algorithm assumes it isn't right. Well, I guess that's an argument for only editing data still owned by that DaveHansen character. I appreciate that you have invested significant time and effort into getting a particular area into good shape. But it seems to me that being able to fix 50 times the area you've already edited, at the cost of some damage to your area, is something that you would appreciate is a good thing. Or is your concern not the map as a whole, but instead the portion of it that you've edited. This argument really rings true to me. With the TIGER import, there were certainly areas of higher-quality data that got destroyed. But, certainly the map benefited overall. There was also another curious side-effect: the areas that *had* personal attention given to them were actually the ones that it was easiest to make decisions about overwriting things. They already had a loving and caring human to fix them up if anything went wrong. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Data Upload
On Sat, 2009-07-18 at 20:07 -0700, Andrew Ayre wrote: I tried bulk_upload.py and it gave me a 404 error. I've used this in the past: http://wiki.openstreetmap.org/wiki/Bulk_upload.pl Evidently it hasn't been updated to 0.6 yet. But, honestly, that shouldn't be *that* hard to do. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Data Upload
On Sat, 2009-07-18 at 22:16 -0700, Andrew Ayre wrote: Thanks. How would I test it without risking putting dummy data or partial data on the public server? I've tried to use another upload script with api06.dev.openstreetmap.org and mysql.dev.openstreetmap.org but they don't appear to be functional (server error 500). Those are the two that I would have tried. Perhaps try the dev@ list and ask for suggestions there. You'll probably have a more broad and smarter audience than us poor US folks. ;) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Deletion of unnecessary TIGER node tags will commence this week-end
On Thu, 2009-08-06 at 21:34 +0200, Frederik Ramm wrote: Allan has made a convincing case about superfluous node tags in this posting on dev: http://lists.openstreetmap.org/pipermail/dev/2009-June/016009.html Huh, I never actually saw that message. I'm OK with this, but mostly because the most useful tag is the tiger:tlid one, and it is actually buggy. I had a bug in the original script that made a big chunk of them worthless. If I ever needed to use that tag, I'd end up having to regenerate them anyway. I'm OK with this. Thanks for letting everyone know. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing duplicates nodes in Iowa/US
On Fri, 2009-08-21 at 08:54 -0500, Travis Rayhons wrote: 3. Does anyone know where I can find the source code to the validator plugin for JOSM? I was thinking I could take that code and replicate the procedure into my script. The code is in SVN: http://svn.openstreetmap.org/applications/editors/josm/plugins/validator/src/org/openstreetmap/josm/plugins/validator/tests/DuplicateNode.java One thing I would encourage you to do is to ensure that nodes are compatible before merging them. I went to some trouble in the original TIGER import to create duplicate nodes for some situations. They're also OK in a number of cases, like where there's an interstate overpass. We may have a single point for the intersection, but we need two nodes since the roads don't actually touch. So, please don't merge *all* duplicate nodes. Check to see, for instance, if they're in different counties. Or, make sure that you're not merging a motorway to a residential street. Sounds like a fun project! -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Garmin OSM map for whole US
For those of you that don't know, Cloudmade has some really cool ready-made maps available for download. I know they work on Garmin devices, but there are probably some others. http://downloads.cloudmade.com/north_america/united_states The problem is that they're made one state at a time. I'm lazy, so I buy large cards for my GPSes and load the whole country on them so I don't ever have to reload maps. But, with the Cloudmade maps, I have to only load a single state at a time. If I want another state, I have to take the card out (or plug the GPS in) and move another state's gmapsupp.img file in. Well, mkgmap has come to the rescue: http://www.mkgmap.org.uk/index.html It allows you to combine several gmapsupp.img files. I've downloaded all of the US states (plus a few territories), and fed them through mkgmap. The result is a single file you can put on your Garmin GPS for the whole country. I've also stuck the bash script in here so you can see how I did it: http://dev.openstreetmap.org/~daveh/garmin/ Just download, bunzip2, rename USA.$DATE.gmapsupp.img to plain 'gmapsupp.img' and move it over to your device. There are a couple of little issues with the way roads get drawn. Some little residential roads get drawn in bold red (is this from the OSM.err stuff?). So, if you know the Cloudmade people who are working on this, I'd like to get in touch with them to make a few minor tweaks. I'd also like to get this off of the dev server and put somewhere a bit better for downloading such a big file. Can anybody at Cloudmade want to share the scripts/programs that are creating these files? Does anybody else have some nice USA extracts that could be used for making garmin maps? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Another shot at a whole-US Garmin map
I decided to try another approach. I used the tile picker from here: http://ulrichkuester.de/OSM/CoordinateToOSMTile.html and got the tiles from here: http://osm.ammit.de/osm/latest/img/ with a little wget and a bash script. I then used the mkgmap commands what Lambertus talks about here: http://forum.openstreetmap.org/viewtopic.php?id=2625p=10 java -Xmx2048M -jar mkgmap.jar --series-name='OSM World Routable' --latin1 --code-page-1252 --description='OSM World Routable' --product-id=53 --tdbfile --gmapsupp *.img The result is here: http://dev.openstreetmap.org/~daveh/garmin/USA-fromtiles.09-06-2009.gmapsupp.img.bz2 It looks quite a bit better than the previous one that I posted. I think those tiles have a bit more detail and don't have the error annotations that the Cloudmade ones do. It still doesn't want to do real routing on my Nuvi, but at least the map looks OK. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Systematic errors in the Maui, Hawaii Data
On Mon, 2009-09-28 at 23:23 -0700, Scott Atwood wrote: However, as nearly as I can tell, very little work seems to have been done on Maui beyond the initial Tiger upload. The problem is, this Tiger data seems to have some large systematic errors, a translation to the north-northwest. I started to manually correct a few ways based on the satellite photos and GPS tracks, but I realized it would probably be far better to either reimport the Maui data with a correction, or apply some automated process to the existing data to translate it to more-or-less the correct location. I'd really prefer not to reimport it. Could you point us to a few areas where we can look at your tracks and the existing data together that exemplify this behavior? Can you quantify large systematic errors? I really don't want to blow it away and re-upload. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Systematic errors in the Maui, Hawaii Data
On Tue, 2009-09-29 at 10:40 -0700, Scott Atwood wrote: The GPS tracklog I uploaded includes data from Wailuku in central Maui, all along the Hana Highway as far as Waianapana State Park near Hana. In all the locations I spot checked (including the ones mentioned above), there appears to be a consistent displacement of approximately 500 meters to the north-northwest of all ways associated with streets. The shoreline ways appear to be more or less accurate. It was pretty easy using JOSM to fix the first example. The second one appears a little less clear cut to me. My best suggestion at this point would be to give JOSM a try. It lets you grab much more interesting sets of data and move them around as a group. I'm a bit hesitant to go moving large swaths of data around in an automated way. First, I don't have any good tools to do it and it'll take some time to code them up. Also, I'm unsure about exactly how widespread and precise the 500m offset is. Does anybody know of any better tools that might help with this? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Systematic errors in the Maui, Hawaii Data
On Tue, 2009-09-29 at 11:20 -0700, Scott Atwood wrote: I spot checked a number of locations all around Maui, and in all the locations I checked, they seem to be affected by the same or highly similar offset to the NNW. Here is another example from the Lahaina area: http://www.openstreetmap.org/?lat=20.88606lon=-156.68522zoom=15layers=B000FTF If you can look into formalizing this, I'd be willing to take a look at it. What I mean is to take some precise measurements from a wide set of samples across the island, probably 20 or 30. Figure out what the displacement vector is at each point, and ensure that it *is* consistent. The worst thing we could do would be to perform such an edit and later realize that we've hurt more than we've helped. I'm just really hesitant to go moving an entire island worth of data based on the problem I've seen so far. The prospect of manually shifting every single street on the entire island of Maui (even in batches within JOSM) is extremely daunting, and strongly inhibits me from wanting to do any work on Maui. And the fact that such enormous errors persist suggests to me that few if any people have done much non-automated work on Maui yet. The question is whether it will take longer for people to do it manually or if doing it in an automated way will be more efficient. Believe me, the prospect of doing a mass edit like that is pretty daunting as well. Can we verify how much editing has been done on Maui? If it is as little as I think, there is little to loose by throwing away the existing data and starting over. I still think re-importing (or some kind of automated batch editing) might be a faster and easier way to fix the problems with Maui. Sure. Just download the entire island and see how many objects have been touched by people other than DaveHansen. JOSM can tell you this pretty quickly. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] TIGER Addressing Import
Is this the most up to date way of keeping addresses? http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Well, I have some perl code that will parse the 2007/2008 TIGER data files. My goal is to get the addresses imported into OSM this time around. Here's some ugly sample output of what I have now. http://sr71.net/~dave/osm/tiger/sherman.osm I don't need any suggestions on it, I just wanted to show people what I have so far. Issues: * I currently have the way combination code turned off. This means that OSM ways are represented 1:1 with the TIGER TLIDs. * Some multi-segment TIGER roads have only a single address range. Do we create segments for each road segment and evenly divide the addresses? Or, do we draw a single address segment going from the first to last node? And, yes, I saw the 2009 data come out. I'll make sure my code works with it. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER Addressing Import
On Sun, 2009-10-04 at 02:24 +1000, John Smith wrote: 2009/10/4 Dave Hansen d...@sr71.net: Is this the most up to date way of keeping addresses? http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Well, I have some perl code that will parse the 2007/2008 TIGER data files. My goal is to get the addresses imported into OSM this time around. Here's some ugly sample output of what I have now. http://sr71.net/~dave/osm/tiger/sherman.osm I don't need any suggestions on it, I just wanted to show people what I have so far. Issues: * I currently have the way combination code turned off. This means that OSM ways are represented 1:1 with the TIGER TLIDs. * Some multi-segment TIGER roads have only a single address range. Do we create segments for each road segment and evenly divide the addresses? Or, do we draw a single address segment going from the first to last node? And, yes, I saw the 2009 data come out. I'll make sure my code works with it. Wouldn't these questions be better going to the import mailing list? There's an imports list? ;) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Changing the account that uploaded the TIGER data
So, I just noticed that this map: http://matt.sandbox.cloudmade.com/?lat=45.528599lng=-122.885771zoom=15layer=2 has my own street listed as unedited TIGER data. I think someone is just using user==DaveHansen as a test for edited vs. uneditied TIGER data. So, I changed the display name. It is now DaveHansenTiger, with an email of osm-ti...@sr71.net. I created a new account 'DaveHansen' with my regular d...@sr71.net email. I promise not to use DaveHansenTiger any more. If I do a new upload, I'll use DaveHansenTiger2009 or something. Cool? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] proposal for deletion: talk-us-ga and
On Wed, 2009-10-21 at 19:40 -0400, Richard Weait wrote: On Wed, Oct 21, 2009 at 7:34 PM, Sarah Manley sarah.m.man...@gmail.com wrote: What is the status of the forum: http://forum.openstreetmap.org? Would building this out more maybe solve some of our problems? Preference for email vs web forum varies from community to community. In my limited experience, more-technical groups tend towards email but there are certain to be counter-examples. An interface that merges email and web forum might be ideal. I believe that the Linux Kernel Mailing List uses such a system but I don't know what the drawbacks and compromises are in that system. There are web interfaces to LKML, but they're all tacked on after the fact to the mailing list. Email is still the main mechanism, although there are some nice web gateways, to be sure. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US-based Server
On Thu, 2009-10-22 at 01:34 +0200, Frederik Ramm wrote: Adam Schreiber wrote: I would hope that and in the future a mapping mirror. The database ought to move to being on more than one server. I am interested to hear your proposals on conflict resolution, or failing that, segmentation of our data. Surely distributed databases are a solved problem these days. :) Having an API mirror that's read-only to users, but kept within a minute or two of the real thing should be OK for most people. There's nothing fundamentally different between that and somebody on a slow connection doing a download of a large area. By the time they have the data, it may be out of date. Writes could quite easily just be proxied (even at the HTTP layer) back to the master machine. I'd bet that OSM is skewed pretty darn heavily to readers anyway. That much could be done with HTTP and minutely planet dumps. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
On Wed, 2009-11-11 at 21:01 -0500, Chris Hunter wrote: My apologies if this has already been reported to the dev mailing list, but I've been running up against a critical/showstopper bug in JOSM 2417 for the past few days. I just tried with 2439 and can't seem to reproduce this. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible destructive bug in JOSM build 2417 - need someone to duplicate
On Wed, 2009-11-11 at 23:01 -0500, Chris Hunter wrote: Thanks. Is 2439 available on the server yet, or is it still in alpha? I re-downloaded the latest beta a couple hours ago and the josm-latest.jar link was still pointing at 2417. I checked it out of SVN and built it myself. I can send along a copy if you wan to give it a shot. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Thu, 2009-11-12 at 10:28 -0600, Ian Dees wrote: Give everyone a chance to work in a constructive way and don't expect others to clean the mess bad import left behind. No wonder there are only few motivated mappers in US. In Canada they do a much better job in integrating the community and don't import every shape file blindly just because it's available. Not to start a holy war over what community is better, but there weren't a whole lot of mappers in the US (at least on talk or talk-us) when we started doing the TIGER import... People were being actively told not to map in the US because we had TIGER coming and it would replace any work you ended up doing. The standard OSM user tries to find their street first. The typical US OSM experience has gone from, My street isn't there to My street is crooked. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Thu, 2009-11-12 at 11:40 -0800, Apollinaris Schoell wrote: On 12 Nov 2009, at 11:29 , Anthony wrote: On Thu, Nov 12, 2009 at 9:14 AM, Andy Allan gravityst...@gmail.com wrote: It's a fairly well established convention that in OSM it's the houses/plots, not the road centrelines, that are addressed. But that doesn't always reflect reality. The reality, at least in many parts of the world, is that the streets are given blocks of potential addresses, and the houses/plots/whatever are given actual addresses from those potential address blocks. Don't know any place except in US where this has been done. So, should we ignore the US for addressing entirely since it is different? Or, should US addressing use a different scheme than the rest of the world? We like being different. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Addressing Question
On Thu, 2009-11-12 at 15:19 -0500, Mike N. wrote: FYI - I applied the experimental script which creates address interpolation ways at - http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py The results are at http://cid-b17e2f1a4d519b13.skydrive.live.com/self.aspx/Public/tl% 5E_2009%5E_45045%5E_addrInterpolation.zip Cool stuff! I've been looking at doing the same thing. Which osgeo python code are you using? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Karlruhe Scheme addressing ways from 2009 TIGER data
So, just like the original TIGER import, I'm now grossly stealing someone else's code: http://svn.openstreetmap.org/applications/utils/import/tiger2osm/shape_to_osm-Tiger.py and I now have made some .osm files with Karlruhe Scheme addressing ways. I'm not going to post them publicly. I did that for the original TIGER, and some enterprising folks took them and uploaded without mentioning it to anyone and it turned into a big mess with no coordination. If anyone wants to see the data for their county, let me know. I'll send you a copy of what I have. All you have to do is convince me that you'll never upload these initial data under any circumstances. :) We'll work on making sure that these data look good and I think some people have some plans on how to get these integrated a bit at a time. -- Dave ___ 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
On Fri, 2009-11-13 at 17:14 -0700, SteveC wrote: Can I have SF county, CA please and Arapahoe County, CO...? http://daveh.dev.openstreetmap.org/secret/stevec-345/ -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On Sat, 2009-11-14 at 21:35 -0500, Anthony wrote: Unless you can point me to some documentation as to what the tiger id *means* (*), I'm not going to think about it at all. Sometimes I keep it, sometimes I delete it, sometimes I delete the whole way and create a new one in its place (without any of the tiger tags). And I'm sure I'm not the only one. I'd prefer that people preserve the TIGER data whenever possible. It's not a primary concern and don't let it slow down your mapping, but it is a useful data point. Let's say we're doing a future TIGER import. Updated roads will have the same TLID between different TIGER revisions and that gives us a good starting point. It's a third bit of data to augment any matching decisions we make based on location and name. We can get along without it, but it *IS* useful. Way history is fine as a backup, but tracing that through splits and joins is not going to be easy. It's much more straightforward to just get it directly. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Sun, 2009-11-15 at 10:59 -0800, Paul Johnson wrote: Dave Hansen wrote: If we can come up with a scheme for getting the addressing imported in a sane fashion and the consensus is that people want it done that way, it'll get imported. There are still quite a few squeaky wheels that like to grumble about TIGER, but I haven't heard a single person say that it did more harm than good. I firmly believe this. TIGER contains so many errors in Oregon, Washington and Idaho that it would likely be easier to start fresh than fix. Just curious, but why weren't you mapping when Oregon and Washington were blank? I'm also curious how you've made so many changes. Have you surveyed it, or are you using TIGER plus Yahoo! imagery? What would you have done without TIGER in these cases? 1) TIGER data is so out of date for urban parts of Cascadia as to be rendered entirely useless. Hmm. I live in urban Cascadia. My subdivision was off by ~100m and had a major street routed wrong. I still don't consider it quite entirely useless. Personally, I find it a lot easier to map with GPS traces, my memory and hints from TIGER than to go out and take detailed notes. It looks to me like you do the same thing, so I'm really surprised that you don't like TIGER. 2) The TIGER import violates one of the most basic principals of OSM: Abbreviations: DO NOT DO IT. I thought the basic principles were to have fun and not copy from other maps. :) 3) Gotta love how TIGER randomly decides some routes aren't freeways when they actually are (and have been for decades). Washington State has literally thousands of miles of expressway and freeway TIGER got wrong. This one might be my fault. There are a bunch of TIGER-OSM feature code mappings, and it's quite possible that I just plain got them wrong in some cases, or that we disagree on how the mappings should have been done. If this is still widespread, I'd be happy to look into it to see what can be done to fix it up. BTW, did you go and survey these thousands of miles of roads to ensure that they really are what you think they are? Are you also saying that you'd rather have a blank space in the map than a wrongly-tagged expressway? The TIGER import should never have been done. I wonder how easy it would be to undo this until an actually suitable data source can be found, since the Fed is doing it on wet bar napkins with cartographers who wear hockey helmets and ride the short bus to work. Might as well photograph a turd and call it aerial photography of central Idaho for the accuracy of TIGER...heck, that photo might actually agree with the TIGER data better! So, what I did initially was go and contact all of the mappers in the US that I could find. I asked them all individually what should be done in their local areas and I believe I was able to follow their wishes without failure. If you want to do the same with TIGER removal, I'd welcome it, especially if you have something superior to contribute. On a small or large scale, we should *NEVER* keep any data in the map just because it is what was already there. TIGER doesn't provide the best possible map, but it did (and does) provide the best map that we have access to. If anyone has better suggestions, I'm open to them. Perhaps I have low standard, but I'd prefer a map of turds to whitespace. :) -- Dave ___ 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
On Sun, 2009-11-15 at 23:30 +0100, Frederik Ramm wrote: Dave Hansen wrote: There are still quite a few squeaky wheels that like to grumble about TIGER, but I haven't heard a single person say that it did more harm than good. Well then you obviously haven't read the two latest entries in Matt Amos' blog here, http://www.asklater.com/matt/wordpress/ (Imports and the Community, parts I and II), with part II ending thus: In conclusion; ... the theoretical model still predicts that imports damage the growth of the editor community. ... Of course Matt's findings are not backed up by a lot of evidence as he himself says, so they might be wrong. And even if they were right, it would be valid (if slightly un-OSM-like) to say to hell with the editor community, I want data now. That's a really cool set of data, very well thought out. It's also interesting to see that the difference in completeness is less than ~5% no matter how much you import to begin. So, you could read it as, imports don't damage the end result of the map... much :) I have a feeling it's all in the noise anyway. My only nit would be that it misses a very important metric: how prolific were the mappers? I know, before my local area got imported, I did a few streets here and there, but only as much as I could survey and note by hand. Now, I can just take GPS traces and make sure that things line up as cab other people from across the globe. So, instead of unique users per time period, it might be interesting to see unique users*nr_edits per time period. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Sun, 2009-11-15 at 14:25 -0800, Sam Vekemans wrote: 1 - A few people (we can call the data conversion team) are in charge of taking the data in it's source form (in this case SHP) We use the tools availble (shp-to-osm.jar and/or shp2osm.py) and are the ones who create a set of 'rules' listed showing the source tags, and how we identify them in OSM. 2 - This team then works and converts this data to OSM format, and makes the files available on a server somewhere. 2a - IF there is alot of conflect then a postProcess is needed. So geobase2osm was created so that we can take an area and use AutoMATCH and see what data needs to be added to osm. 3 - When these .osm files become available on a server, it's up to the local area mappers to decide on what they want todo with the data. 3a - if the data is too complicated, local area mappers tell the conversion team, and this team works out the bugs and learns from everyone else on how to handle it. Yeah, and that does sound like a really nice way to do it, especially when there is existing data. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Sun, 2009-11-15 at 14:33 -0800, Dave Hansen wrote: Yeah, and that does sound like a really nice way to do it, especially when there is existing data. Anybody want to be on the USA conversion team? :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Talk-ca] TIGER considered harmful
On Sun, 2009-11-15 at 14:49 -0800, Dan Putler wrote: The upshot, for a number of US counties you would rather use the county centerline road data rather than TIGER data as the basis of the import. That's really good news. This is exactly what happened for Massachusetts. They had better data, and were willing to get it imported in lieu of TIGER. I think those two things are the key: 1. Data exists in a form that it can be imported 2. There are willing people to do the import If we don't have both of those things, it makes sense to skip doing something like TIGER and use the local data. But, I think just having the data be theoretically available to import should be enough to stop an inferior but available set getting imported. But, I'm not sure we're going to do any truly automated addressing imports in the US, anyway. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Sun, 2009-11-15 at 18:28 -0500, Kate Chapman wrote: Maybe I'm confused about the address versus road information. I would think the address point would be the front door of the building and would not be a relation to the road. So the node of the address and the way of the road would not be on top of each other. You're right, they're not geographically right on top of each other. But, in OSM we have these relation data primitives to tie different thing together. In this case, we use relations to tie addresses and roads together. I think this is in case of things like the road getting moved. The address nodes at least don't become orphans. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] [Talk-ca] TIGER considered harmful
On Sun, 2009-11-15 at 18:54 -0500, Anthony wrote: On Sun, Nov 15, 2009 at 6:17 PM, Dave Hansen d...@sr71.net wrote: On Sun, 2009-11-15 at 18:11 -0500, Kate Chapman wrote: What's wrong with doing automated addressing imports in situations where we have point level address data? The issue is that it may not line up with the roads at all. Well, address locations don't always line up with roads. That's not a bug, that's a feature. Though I suspect you mean something else, and I'm not sure quite what it is. There's nothing wrong with doing point-level address imports. The only thing I would suggest is ensuring that we connect those points ways or whatever to the roads that represent them somehow. One way to do that is relations. They ensure that you can't, for instance, delete the road without also considering how deleting the road might affect addresses on that stretch of road. We also need to ensure that we *find* the roads to which it refers to ensure that we get the relations done properly. There's no need for relations, which I would think you'd be aware of, since you're not using relations with your TIGER address import I'm not done yet. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map Update
On Sun, 2009-11-15 at 21:17 -0500, Richard Welty wrote: On 11/15/09 6:45 PM, Dave Hansen wrote: and put in the /garmin/ directory on your device (if you have an SD card unit). I'll be updating these periodically as I feel the need. I think I also have my methods down to a point where I could just script it and make these weekly or something, if anyone is interested. do you want reports on observed problems? i note that the way data seems very incomplete in the Albany, NY area. but then, i don't know what's really supposed to be in these maps. Is there OSM data in the area to begin with? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] Karlruhe Scheme addressing ways from 2009 TIGER data
On Mon, 2009-11-16 at 15:05 +, Andy Allan wrote: So please, turn away from imports and work on getting mappers in charge, especially out pounding the streets. The outcome will be much, much better in the end, and that end will come much, much quicker. I think TIGER was a success if only because of all the Europeans we tricked into fixing our roads for us. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Non-Integer addresses
On Mon, 2009-11-16 at 16:05 -0600, SteveC wrote: any idea where...? maybe we could get some locals to investigate what they are? I added an addr:raw tag so we can find this in the future. But, here's one example. There only appear to be a few of these per county. I *think* they're mostly just garbage. The other county that I looked at had it isolated to this court: http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=LO98+SE +Braemark +Ctsll=45.429105,-122.543643sspn=0.0016,0.002406ie=UTF8hq=LO98+SE +Braemarkhnear=Connecticutll=45.429107,-122.543644spn=0.003185,0.004812z=18 But, as you can see, there's at most one house on that thing and there was a whole range of addresses. node id='-354523' action='create' visible='true' lat='43.358025' lon='-124.211401' tag k=addr:housenumber v=38-200 / tag k=addr:postcode v=97420 / tag k=addr:street v=E Johnson Ave / tag k=addr:state v=Oregon / tag k=addr:county v=Coos, OR / tag k=addr:country v=US / /node node id='-354525' action='create' visible='true' lat='43.358031' lon='-124.212018' tag k=addr:housenumber v=72-252 / tag k=addr:postcode v=97420 / tag k=addr:street v=E Johnson Ave / tag k=addr:state v=Oregon / tag k=addr:county v=Coos, OR / tag k=addr:country v=US / /node node id='-354522' action='create' visible='true' lat='43.357860' lon='-124.211404' tag k=addr:housenumber v=1 / tag k=addr:postcode v=97420 / tag k=addr:street v=E Johnson Ave / tag k=addr:state v=Oregon / tag k=addr:county v=Coos, OR / tag k=addr:country v=US / /node node id='-354524' action='create' visible='true' lat='43.357866' lon='-124.212021' tag k=addr:housenumber v=99 / tag k=addr:postcode v=97420 / tag k=addr:street v=E Johnson Ave / tag k=addr:state v=Oregon / tag k=addr:county v=Coos, OR / tag k=addr:country v=US / /node tag k=addr:raw v=38-200:72-252:1:99 / way id='-354526' action='create' visible='true' nd ref='-354523' / nd ref='-354525' / tag k=addr:interpolation v=all / tag k=addr:postcode v=97420 / tag k=addr:street v=E Johnson Ave / tag k=addr:state v=Oregon / tag k=addr:county v=Coos, OR / tag k=addr:country v=US / tag k=source v=tiger_import_v0.3_20091116231244 / tag k=attribution v=tiger / /way -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map Update
On Mon, 2009-11-16 at 19:46 -0500, Bill Ricker wrote: is perhaps the file too big for some models of garmin to process in real time? i suppose, but it really seems like a couple of badly rendered tiles. I'll try it on my 76csx eventually . That's what I've got. It seems to work pretty darn well. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Mon, 2009-11-16 at 16:24 -0500, Matthias Julius wrote: IMHO it is unfortunate this was not done during the TIGER import. It would have been easy enough. Sure. But, there were 50 other things that were easy enough to do. Joining county borders, eliminating motorway overpass intersections, etc... I'm pretty sure I didn't refuse the help of anyone offering to do this. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map Update
On Wed, 2009-11-18 at 18:50 -0500, Greg Troxel wrote: Dave Hansen d...@sr71.net writes: I updated my whole-US map for Garmin devices. It's stolen from the Cloudmade state gmapsupp images that you can find here: http://downloads.cloudmade.com/north_america/united_states/ and pieced together with mkgmap and wget. Just take the gmapsupp.img file from here: http://daveh.dev.openstreetmap.org/garmin/ and put in the /garmin/ directory on your device (if you have an SD card unit). I'll be updating these periodically as I feel the need. I think I also have my methods down to a point where I could just script it and make these weekly or something, if anyone is interested. I have wondered about making all-us garmin data, and think there might be problems with the gmapsupp.img you made. Perhaps I'm confused, but I'm throwing these points out for discussion: --route is AFAIK not turned on in cloudmade, so those maps wouldn't be routable. If cloudmade has enabled routing, that would be good to know. (Plus there's the noname roads being big and red.) Yeah, the second batch I posted from Lambertus should be routable. I tried at least going a few miles down the road from my house, and it seemed to work OK. roads are disconnected at state boundaries due to being cut with a non-splitter tool. (splitter has special logic to insert nodes on ways at tile boundaries.) I think I had this problem when using e.g. massachusetts.osm.bz2 and vermont.osm.bz2 together into splitter - driving from central mass to vermont had routes reverting to basemap but when I crosssed into VT they became sensible. When making maps of a state, splitter makes tiles that fit the x/y bbox, and these will in general go beyond the state border. When you do this with neighboring states, typically you'll get overlapping tiles that will have data in the state and no data out of state, mirror image. It's not clear what the draw order is for areas covered by both tiles, but any particular order can't be right. Yeah, that's true. But, take a look at the new set from Lambertus. He does it with non-overlapping (generally) bounding boxes. I'm not sure the second set I posted have this issue. To make a gmapsupp.img for all of the US, I was going to get a US extract of the planet, use splitter, and then use mkgmap with routing enabled. I would then use gmapibuilder to put into RoadTrip so I can load the parts I want together with the proprietary map (for when I actually have to get somewhere :-(). That should address all three issues above. Cool! Please do share when you get this done, it would be awesome. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map Update
On Thu, 2009-11-19 at 12:54 -0500, Greg Troxel wrote: This method the routing-broken-at-state-borders problem, but not the overlapping tiles problem. It should work with a united_states.osm.bz2; apparently that's a high enough fraction of the size of the planet that it isn't produced. Apollinaris sounds like he has a USA extract. In any case, we really should make one periodically and publish it. There isn't one available as far as I know. I'm sure it isn't *horribly* difficult, but I haven't played with planet files in a while. I'm sure someone else can point us to the right way much more quickly than I can figure it out. I'm dumb. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER considered harmful
On Thu, 2009-11-19 at 13:29 -0800, Paul Johnson wrote: Used state data instead, if I were to do a mass import. Oregon GEO knows what they're doing, the US Census (along with the rest of the federal government) barely acknowledges we exist. Which would you rather trust? 1) Known good data from a regional government agency that's receiving it's information directly from the Department of Transportation... or 2) A bunch of minimum wage lackeys who don't want to be out in the rain and aren't motivated to do it right? Heh, I didn't even know we had Oregon data available. If someone wants to work to get this data into OSM format, I'd be happy to help. We could probably replace bad TIGER spots or use it to fix up existing data. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] San Francisco / Bay area projects
On Wed, 2009-12-02 at 03:55 -0500, Dale Puch wrote: I think the idea was that there wasn't that much traffic that it would bother the talk-us group, and what was there the rest of us could possible benefit from. Yeah, that's what I took from it too. It will be a wonderful day when we have so much activity on this list that there's a desperate need to break it up somehow. As talk-us list dictator, I hereby declare that any local discussions about anywhere in the country are more than welcome here. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER fixup guidance wanted
On Thu, 2009-12-03 at 15:50 -0800, Jeff Barlow wrote: I'm new here and a little unsure of how best to proceed. I'm having some issues getting JOSM to run but I expect to get those sorted out soon. Then I want to start working on TIGER fixup. I'm located in central Oregon, near Bend. I see a lot of mapped roads around here, imported from TIGER, that are clearly very wrong. Cool, more Oregon mappers! :) Should I simply delete these or just change their tags so they don't render as roads? If the latter, how should they be tagged? If you've been there and can confirm that there's nothing there, or they're bad enough that you can't figure out what they correspond to, delete them. But, I personally don't want people deleting everything that doesn't appear on aerial imagery. OTOH, there are new roads that aren't in the currently imported version of the TIGER data. These I can clearly GPS and map. Excellent. TIGER was from 2005 at best. In all of these cases I'm unsure of how my edits will coexist future imports of TIGER 2009, 2010, etc. For instance if I just delete bogus roads will they come back like zombies? Perhaps there's some guidance in the Wiki about all this but I have yet to come across it. I'm not sure we'll ever import a full TIGER set again. We'll certainly do everything we can to not overwrite any work that people are doing now, especially with roads that people deleted in their entirety. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] HI: Hawaii GIS Data
On Sat, 2009-12-05 at 00:12 +, Shaun McDonald wrote: Why oh why oh why do some people insist on wasting time trying to import loads of data? Mapping is fun, but I personally think it is more fun when you're enhancing someone else's work rather than starting from a blank slate. Whatever floats your boat, I guess. Anyway, Scott, I'd encourage you to find some specific goals that you'd like to achieve with the import. It may not be worth importing things just because they are available. Is there something specific missing from or lacking in OSM that the import could help with? -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] HI: Hawaii GIS Data
On Fri, 2009-12-04 at 16:22 -0800, Dave Hansen wrote: Anyway, Scott, I'd encourage you to find some specific goals that you'd like to achieve with the import. It may not be worth importing things just because they are available. Is there something specific missing from or lacking in OSM that the import could help with? The thing that caught my eye, personally, was the trails. But, I'm a hiker, so that's what I care about by default. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] HI: Hawaii GIS Data
On Sat, 2009-12-05 at 00:12 +, Shaun McDonald wrote: Please take a read of http://www.gravitystorm.co.uk/shine/archives/2009/11/10/the-pottery-club/ Don't forget that OSM was turning away US mappers for a long time telling them to come back once TIGER was imported. It isn't that way any more, thank goodness. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Issues in New Mexico
On Mon, 2009-12-14 at 12:07 -0500, James Umbanhowar wrote: Does anyone know why the area around around Raton, NM looks like it is melting? I don't think it even renders in Osmarender. http://www.openstreetmap.org/?lat=36.93134lon=-104.46384zoom=16layers=B000FTF You have a couple of nodes that aren't quite in NM any more in some of those ways: node id='141799398' timestamp='2009-12-07T02:23:16Z' uid='131218' user='Chris CA' visible='true' version='5' lat='89.624567' lon='-104.4524709' / Looks closer to Santa than to New Mexico. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Issues in New Mexico
On Mon, 2009-12-14 at 09:18 -0800, Dave Hansen wrote: On Mon, 2009-12-14 at 12:07 -0500, James Umbanhowar wrote: Does anyone know why the area around around Raton, NM looks like it is melting? I don't think it even renders in Osmarender. http://www.openstreetmap.org/?lat=36.93134lon=-104.46384zoom=16layers=B000FTF You have a couple of nodes that aren't quite in NM any more in some of those ways: node id='141799398' timestamp='2009-12-07T02:23:16Z' uid='131218' user='Chris CA' visible='true' version='5' lat='89.624567' lon='-104.4524709' / Looks closer to Santa than to New Mexico. http://www.openstreetmap.org/browse/changeset/3312188 -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Warning: Potential Flamewar] Clarifying Interstate Relations
On Sun, 2010-02-07 at 14:42 -0500, Richard Welty wrote: i concur with the notion of splitting at state lines. i also think that the longer US routes need to be handled in a similar manner. Yeah, that's sane. If for no other reason than the fact that the mile markers reset at state lines. I guess they're also the maintenance boundaries. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map (02-10-2010) update
The map is up to 2.8GB! These are based off of Lambertus's work here: http://garmin.na1400.info/routable.php I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/ There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map (02-10-2010) update
On Wed, 2010-02-17 at 16:05 -0500, Mike N. wrote: Many thanks for this update - it has come in handy many times since the last update. I was about to check with you to see if there was any way to update it, but you beat me to it! It's just about at the point where I can automate it to rebuild them whenever Lambertus kicks off an update himself. I'll let everyone know when I get this set up. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Motorway vs trunk
On Fri, 2010-02-26 at 15:50 -0500, Richard Welty wrote: On 2/26/10 3:14 PM, Nakor Osm wrote: What is the distinction made between trunk and motorways for tagging in the US. As an example should this portion of US41 ( http://www.openstreetmap.org/?lat=41.8967lon=-87.6177zoom=14 http://www.openstreetmap.org/?lat=41.8967lon=-87.6177zoom=14 ) be a motorway or a trunk? for all practical purposes, a trunk is a motorway-wannabe, but with grade level crossings of some sort, either with stop signs for the lesser roads, or traffic lights. you generally won't see driveways or businesses directly on trunks, there will often be frontage roads for that. the portion of US 41 you point out is a bit schzoid, mostly grade separated but with a scattering of grade level crossings. the points with grade level crossings should certainly be trunk. Well, it's going to look goofy on the map to have dotted green and blue lines. I'd say that you also need to consider how long the segment is. I have a divided road with fences on both sides and limited access near my house. There's a 25ft stretch of it with limited access. Is that a motorway for 25ft? ;) I think that motorways need to be relatively long. At least a number of miles of solid motorway to *be* a motorway. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New List: osm-professional
On Wed, 2010-03-03 at 17:57 +0100, Frederik Ramm wrote: Serge Wroclawski wrote: Most people know what professional behavior is, and if things get out of hand, we'll talk to them. Semi-moderated means at first, all post and all people will be moderated. Over time, we'll probably get go of the reins a bit Ok. I would like to be part of a professional OSM mailing list but not one that is moderated. I guess I'll just ask for a second, unmoderated list to be created ;-) If things ever got severely out of control on talk-us, I think I'd be OK with switching the moderation bit on. But, I don't recall ever getting *anywhere* close to doing that. Maybe with this thread. ;) Serge, it looks like there may be a bit of sensitivity with calling lists moderated. Although I think it's fair to spell out the expectations: * The list's express purpose is to cater to those who wish to work on or with OSM in a professional capacity * Posters are expected to be welcoming to others, keep flamewars to a minimum I think it's also fair to say that if there are people who are not being welcoming to others that they will be asked to unsubscribe from the list. It goes without saying on any list that if anyone misbehaves, they'll get their moderation bit turned on. If that fails repeatedly, then perhaps move to full moderation. I'd be much more apt to subscribe to a list like that than one which starts out (and stays) moderated. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map update - 19-03-2010
These are based off of Lambertus's work here: http://garmin.na1400.info/routable.php I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/19-03-2010 There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map update - 19-03-2010
On Mon, 2010-03-22 at 22:46 -0400, Bill Ricker wrote: So do all SD-cable Garmins handle huge map files equally well or not ? I think they should. My 60csx didn't have SDHC support when I bought it, but it got magically added in a firmware update. I'm still not sure how they did that. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map update - 25-03-2010
So, I finally set these up to be fully automated. If these messages get sent once a week or so, should I keep them coming to talk-us? -- These are based off of Lambertus's work here: http://garmin.na1400.info/routable.php I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/25-03-2010 There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Whole-US Garmin Map update - 25-03-2010
On Sat, 2010-03-27 at 13:55 -0600, Val Kartchner wrote: Dave, I'm a regular contributor to OSM, and a subscriber to the US mailing list. I followed the link to the routable Garmin maps that you have made available. I'm assuming that these are for the US since they are on the US mailing list. However, the contiguous US (CONUS) goes from approximately -66.5 to -125. I didn't see any of the ranges that you have that will go this far east in the western hemisphere. Am I mistaken about the extent of CONUS? So, this isn't the continental US that I'm talking about. The algorithm looks like this: for each garmin image... does it intersect a state polygon? If so, add it to the set The result will be clear if you look here: http://garmin.na1400.info/routable.php in the very upper-right corner. See the few Aleutian islands that cross 180/-180 longitude? So, the images are named a bit strangely. The names mean: This image contains all of the tiles which have middle points between these two latitudes. The end result is that I put the Aleutian island tile next to Maine. I'm too lazy to fix it at the moment. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map update - 09-04-2010
Forwarded Message From: Dave Hansen da...@openstreetmap.org To: d...@sr71.net Subject: Whole-US Garmin Map update - 09-04-2010 Date: Thu, 15 Apr 2010 16:19:45 +0100 These are based off of Lambertus's work here: http://garmin.na1400.info/routable.php I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/09-04-2010 There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map update - 16-04-2010
These are based off of Lambertus's work here: http://garmin.na1400.info/routable.php I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/16-04-2010 There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Resigning in protest
On Tue, 2010-05-11 at 19:20 -0400, Chris Hunter wrote: I have major philosophical issues with the way the license change is being handled, and feel that I can no longer participate in the OSM project. I honestly haven't paid much attention to it. I figured it was pretty messy, but legally necessary for OSM to continue to be adopted into certain environments. What did you find objectionable? Maybe I'll be turned off by it too. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Resigning in protest
On Thu, 2010-05-13 at 01:39 +0200, Frederik Ramm wrote: Terribly thought out process. Terrible idea in the first place. IMHO the terrible idea was to start out with CC-BY-SA in the first place; had we simply been PD all along, nobody would have made a fuss and we could have saved zillions of man-hours in license working group time and heated mailing list discussions. Some very smart lawyers at very big companies in the US claim that PD doesn't really exist, outside what would otherwise be government-held copyright. PD might make it worse. Let's just blame the lawyers. :) -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Reply-to field in list messages
On Thu, 2010-06-10 at 16:59 -0400, David ``Smith'' wrote: Why doesn't the talk-us list use the reply-to field so that simple replies go to the list, not just the original poster? The newbies list does that. Every other e-mail list I've ever been on does that. So why not this one? It's a religious topic, indeed. Every email list I'm familiar with does the opposite of every one of yours. ;) There are about 200 subscribers, currently. If you want the default changed, I'm open to it, although I probably won't change it unless there's a pretty strong consensus for it, and little dissent against a change. Let's not argue the merits of either approach. But, if you have an opinion on it either way send me a quick, private mail. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Percentage of data imported vs mapped
On Wed, 2010-06-23 at 12:05 -0400, Richard Weait wrote:
On Wed, Jun 23, 2010 at 11:42 AM, McGuire, Matthew
matt.mcgu...@metc.state.mn.us wrote:
Does anyone know the percentage of OSM data that is imported vs mapped in
the US? How does this compare to other countries?
When TIGER was imported it dominated the database and contributed data
from all countries combined. The US community is growing and
individual contributions are growing, but so are imports from other
sources.
In Oregon, 48% of the objects have been most recently modified by
non-TIGER sources. Calculated this way:
grep -o 'user=[a-zA-Z0-9]*' oregon.osm | sort | uniq -c | sort -n | grep -vi
tiger | awk '{sum += $1} END { print sum;}'
grep -o 'user=[a-zA-Z0-9]*' oregon.osm | sort | uniq -c | sort -n | awk '{sum
+= $1} END { print sum;}'
It's higher than I expected, personally. Not too shabby.
-- Dave
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
