Re: [Talk-us] intertwined ways in Austin TX
I remember this being referred to as braiding if that jogs anyone's memory... I think I remember seeing it in SVN somewhere. Beau On Thu, Jul 24, 2008 at 9:37 AM, Jessica Forbess [EMAIL PROTECTED] wrote: Hey, I'm in Austin TX right now, and while looking for stuff to correct, I noticed all of the boulevard streets have the two ways intertwined at each intersection, messing up the oneway settings, and generally not being right. SteveC mentioned someone out there has a script to correct this specific problem? thanks, jess ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [Talk-us] TIGER 2007 files
I unzipped the King County edges file and made do with that. Here's my proof of concept: http://beaugunderson.com/osm/ The first map controls the second in terms of panning and zooming. You can see that the 2007 data is leaps and bounds ahead of the TIGER data that got imported (at least in this area). The freeway interchanges were very bad and quite low resolution before, they're now quite good. The map is centered on 47.61038, -122.20068; just East of Seattle. Beau On Sun, Jul 20, 2008 at 9:28 PM, Beau Gunderson [EMAIL PROTECTED] wrote: I just tried to create the tool you proposed but the TIGER shapefiles are 8gb zipped and after downloading them I've only got 6gb free on my webserver. :) To download all the shapefiles you can use: # wget -r -A *edges* ftp://ftp2.census.gov/geo/tiger/TIGER2007FE/ After that I was going to write a script to create a Mapnik XML file with them all in it and then display that with OpenLayers side-by-side with the current OSM map using Mapstraction and this as a reference: http://www.mapstraction.com/ljn.php Maybe someone with more space can give it a try... I'm still clearing space on my server so I may get farther along at some point! Beau On Sun, Jul 20, 2008 at 6:39 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yeah, I knew trying to do sequential pulls would create a number of coordination issues, I just didn't know what the plan was. I figured someone smarter than me had figured out a cool way to do it, like keying on the tiger_reviewed tag and automatically replacing centerline data that hadn't been reviewed with the revised entity in TIGER. Things could still get messy where a user has added new subdivisions features before the TIGER data release with the official position data for those streets. You'd need some sort of way to flag street centerlines that are too close to be reasonable, or cross, or whatever, and somehow keep it from flagging every divided highway in the system. Doesn't sound fun. The idea of creating tools for users to pull thier county of interest and compare the new TIGER with OSM might be useful. I thought I saw where Steve C had done a comparison of OSM's centerline info with Google/NAVTEQ's info for an area of interest in an automated way (although I could certainly be mistaken on that point). A highlight tool for OSM vs. new TIGER for a county sized region with arial imagery in the background would be an awesome tool to rapidly scan for things that may have been missed...or areas where TIGER is really out of the loop :-) All in all I'm in awe of the data conversion process that has already taken place. I've been playing around with the streets in my city (Stockton, CA) and I can't imagine having a situation similar to the UK where every single street had to be loaded by hand from scratch! Thanks Dave for the great work! -Mike -- Beau Gunderson [EMAIL PROTECTED] wrote: Another alternative may be to be for the people working in an area they care about to do those steps manually. I'm very interested in the Seattle data because the TIGER data that's there now has some definite gaps. :) Beau On Sun, Jul 20, 2008 at 2:56 AM, Dave Hansen [EMAIL PROTECTED] wrote: 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
Re: [Talk-us] TIGER 2007 files
I just tried to create the tool you proposed but the TIGER shapefiles are 8gb zipped and after downloading them I've only got 6gb free on my webserver. :) To download all the shapefiles you can use: # wget -r -A *edges* ftp://ftp2.census.gov/geo/tiger/TIGER2007FE/ After that I was going to write a script to create a Mapnik XML file with them all in it and then display that with OpenLayers side-by-side with the current OSM map using Mapstraction and this as a reference: http://www.mapstraction.com/ljn.php Maybe someone with more space can give it a try... I'm still clearing space on my server so I may get farther along at some point! Beau On Sun, Jul 20, 2008 at 6:39 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yeah, I knew trying to do sequential pulls would create a number of coordination issues, I just didn't know what the plan was. I figured someone smarter than me had figured out a cool way to do it, like keying on the tiger_reviewed tag and automatically replacing centerline data that hadn't been reviewed with the revised entity in TIGER. Things could still get messy where a user has added new subdivisions features before the TIGER data release with the official position data for those streets. You'd need some sort of way to flag street centerlines that are too close to be reasonable, or cross, or whatever, and somehow keep it from flagging every divided highway in the system. Doesn't sound fun. The idea of creating tools for users to pull thier county of interest and compare the new TIGER with OSM might be useful. I thought I saw where Steve C had done a comparison of OSM's centerline info with Google/NAVTEQ's info for an area of interest in an automated way (although I could certainly be mistaken on that point). A highlight tool for OSM vs. new TIGER for a county sized region with arial imagery in the background would be an awesome tool to rapidly scan for things that may have been missed...or areas where TIGER is really out of the loop :-) All in all I'm in awe of the data conversion process that has already taken place. I've been playing around with the streets in my city (Stockton, CA) and I can't imagine having a situation similar to the UK where every single street had to be loaded by hand from scratch! Thanks Dave for the great work! -Mike -- Beau Gunderson [EMAIL PROTECTED] wrote: Another alternative may be to be for the people working in an area they care about to do those steps manually. I'm very interested in the Seattle data because the TIGER data that's there now has some definite gaps. :) Beau On Sun, Jul 20, 2008 at 2:56 AM, Dave Hansen [EMAIL PROTECTED] wrote: 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 Click to get the coolest ring tones on your phone, fast and easyhttp://thirdpartyoffers.juno.com/TGL2132/fc/Ioyw6iifCVPFv1cMm8bZA6J2elt4zxyi22JF15EFg2dhXcklOKozXM/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
Re: [OSM-talk] openstreetmap
I'd be glad to be a part of the community, and as far as I can tell after a few days of looking around at least 150.000 WPs of my collection are not in openstreetmap.org - yet. Were those 200,000 POIs collected by you or derived from public domain sources? That sounds quite a lot of work for a single person!!! Just for a sense of scale, I drove to Panama from Seattle, WA and when I last uploaded to OSM I had 968,793 points (counted with grep \trkpt *.gpx | wc -l) this was about 80% of the total drive. :) Beau ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] National borders in the British Islands
Surprised no one has posted this link yet: http://qntm.org/?uk A nice Venn diagram of the UK. :) Beau On 5/29/08, Robert (Jamie) Munro [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dermot McNally wrote: | | But the clue here is that we're discussing the appropriate use of | boundary tagging, specifically a thing we call admin_level. I guess | none of us will disagree that Germany and the UK get to exercise a | higher level of administration than a country like England or Wales? I've always thought that England / Scotland / Wales / Northern Ireland forming the UK are pretty similar to the 50 states forming the USA - I think it would be reasonable to use the same markings on the default map to divide them. Legal purists may want different (or extra) tags in the database on the grounds that it's a completely different situation, but they could be rendered the same. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg+rxIACgkQz+aYVHdncI0KeQCg5TiY6CzGVhPCi8P+Vf9AmQam f4EAniZKu7dP40obhJ115MxVNOTxSWor =+A58 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Islands in lakes
Sidenote: I'm sure I'm not the only person who has hit those keys on informationfreeway wondering what they did and messed up some tiles... Might be good to have a popup explaining things the first time you press one and then store that you've seen it in a cookie. On Thu, May 29, 2008 at 4:07 PM, Donald Allwright [EMAIL PROTECTED] wrote: Hi All, Can anyone explain what's gone wrong here: http://www.informationfreeway.org/?lat=-15.756477951963221lon=-69.56994035747516zoom=12layers=B000F000F ? Following the discussions last week about how to tag islands in lakes so that they render properly, I've gone round and re-worked the tags for islands in Lake Titicaca (which disappeared in Mapnik this week, presumably as a result of a tagging error). To be sure I had got it right I sought out a similar feature set to examine the tags, and found this: http://openstreetmap.org/?lat=60.873lon=14.822zoom=11layers=B00FF which is displayed correctly in both osmarender and mapnik. It seems that most of the tiles are now rendering correctly, but some of them are rendering inverted. I've had to mark a number of tiles as blank land or blank sea too (via informationfreeway.org, I presume pressing 'l' or 's' at zoom 12 has the desired effect?). I can't see how it can be an error in the track that marks the island, as part of it is rendered correctly. Any clues as to what's gone wrong? (The osmarender tiles at zoom 12 are all messed up in this area, I'm just concentrating on z=12 for now). Cheers, Donald When the winds of change start blowing, some people look for shelter. Others build windmills. -- Ancient Chinese Proverb. http://donaldallwright.blogspot.com -- Sent from Yahoo! Mailhttp://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52418/*http://uk.docs.yahoo.com/nowyoucan.html. A Smarter Email. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
What about using the Python bindings and actual Mapnik objects to create the XML file? It should be able to save an XML file, and that way you can abstract out all of the XML text from your program too... Beau On Wed, May 28, 2008 at 3:05 AM, Steve Hill [EMAIL PROTECTED] wrote: On Tue, 27 May 2008, Andy Allan wrote: Now, if someone is volunteering to make a concise definition format that can be pre-processed into the mapnik XML format (or mapnik python code, or even just read by a modified mapnik directly, or whatever) then I'd absolutely love to SEE THE WORKING CODE. That osm.xml is an unwieldy beast isn't in question, nor are the myriad of possibilities to improve it - what is lacking is working alternative. For OpenPisteMap I create the XML using some PHP code: https://public.subversion.nexusuk.org/trac/browser/openpistemap/trunk/scripts/mktemplate.php I've not converted the entire XML file yet, and I don't pretend it is a universal solution, but I find it easier to work with than the raw MapNik XML file. It would be nice to have some kind of cascading language so that styles can be defined for each object at the top level and then modified for each zoom level, but I suspect no one has the time to do it (I certainly don't). - Steve xmpp:[EMAIL PROTECTED] [EMAIL PROTECTED] sip:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Bridge rendering for freeway overpasses/interchanges in Mapnik and Osmarender
Here's a freeway interchange near Seattle, WA in Mapnik: http://www.openstreetmap.org/?lat=47.63265lon=-122.18557zoom=17layers=B00FF And here's the same in Osmarender: http://www.openstreetmap.org/?lat=47.63265lon=-122.18557zoom=17layers=0B0FF The 'wings' at the start and end of the bridge in Osmarender don't really work when rendering complex freeway interchanges like this, they tend to clutter things up to my eye. The things that do look great in the Osmarender style are the additional white line between the way and the edge and the lighter gray for the edge color. The options I can think of to reduce the clutter would be to either remove the wings from Osmarender (which is probably not a good idea because they do look nice when not used for freeway interchanges) or to create a new tag or an additional option to the bridge tag (bridge=overpass?). The Mapnik version may benefit from looking more like the Osmarender style too. What do you all think? Thanks, Beau ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] National borders - mapnik
The US national border with Canada is all tagged with admin_level=4, border_type=state, border=administrative... It also has the left/right countries (at least the bit I looked at in WA did). How should state borders that are also national borders be tagged? Does setting admin_level=2 fix the whole problem? As you can see, they're not currently visible at low zooms: http://www.openstreetmap.org/?lat=48.83lon=-118.46zoom=7layers=B00FF Beau On Wed, May 28, 2008 at 1:21 PM, Steve Chilton [EMAIL PROTECTED] wrote: The latest mapnik stylesheet has the National borders moved from coming in at z10 to coming in at z7. Now zooms to z6 show the borders as thin blue lines taken from the shape files, and then switch to OSM data at z7 using a slightly thicker purple line. Not all borders show, for one of two reasons - either they are not digitised or are not tagged appropriately. So, it would be useful if folk have a look at their own country/area at z7. Does in show correctly? If not: 1 - check whether it has been digitised. If not - is there a valid, non-copyrighted source for putting in the border alignment. 2 - check whether it is tagged boundary=administrative, admin_level=2. If not - change the tagging to that so that it may show. As a reminder, admin boundaries should be tagged for the admin_level that they are (at the highest level). Country/national borders are always admin_level=2. Internal borders should be tagged according to the suggested schema for that particular country. Details are on the wiki at: http://wiki.openstreetmap.org/index.php/Key:boundary which also explains the accepted way to tag for the countries on either side of the border. Cheers STEVE ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] National borders - mapnik
Gotcha... I guess my question is this: Does it matter if all of those US states don't have a state border way at the top and there's just one long continuous national border? Or should those borders be left the way they are, duplicated, the duplicates combined and then a national border made from that, so that there are state borders and the national border way next to (or on top of) each other? Beau On Wed, May 28, 2008 at 1:49 PM, Ted Mielczarek [EMAIL PROTECTED] wrote: On Wed, May 28, 2008 at 3:42 PM, Beau Gunderson [EMAIL PROTECTED] wrote: The US national border with Canada is all tagged with admin_level=4, border_type=state, border=administrative... It also has the left/right countries (at least the bit I looked at in WA did). How should state borders that are also national borders be tagged? I believe those were all imported from the TIGER polygon data, so they were just state borders originally. The ways might need some massaging to make a continuous national border. -Ted ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] National borders - mapnik
Please clarify one thing: any border that is both a state and national border should be tagged at the highest level (in this case national, admin_level=2) To me this sounds like there is just one way for the state/national border... but... and the state borders will come in too, with their appropriate style. This sounds like there are two ways, one for the state border and one for the national border. This seems to make the most sense to me given the second sentence quoted above. Beau On Wed, May 28, 2008 at 2:06 PM, Steve Chilton [EMAIL PROTECTED] wrote: Logically, any border that is both a state and national border should be tagged at the highest level (in this case national, admin_level=2). Similarly in UK any border that is both county and country should be tagged at highest level (country, admin_level=2). That way all the country borders will show at designated zoom levels. When you move to a level that state (or whatever) comes in the country border will already be there (in its appropriate style) and the state borders will come in too, with their appropriate style. Currently there is an /Else filter which picks up borders that have no admin_level set, but it necessarily doesn't come in till higher zooms, which appears to the case for your example below. Cheers STEVE -Original Message- From: [EMAIL PROTECTED] on behalf of Beau Gunderson Sent: Wed 5/28/2008 8:42 PM To: Steve Chilton Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] National borders - mapnik The US national border with Canada is all tagged with admin_level=4, border_type=state, border=administrative... It also has the left/right countries (at least the bit I looked at in WA did). How should state borders that are also national borders be tagged? Does setting admin_level=2 fix the whole problem? As you can see, they're not currently visible at low zooms: http://www.openstreetmap.org/?lat=48.83lon=-118.46zoom=7layers=B00FF Beau On Wed, May 28, 2008 at 1:21 PM, Steve Chilton [EMAIL PROTECTED] wrote: The latest mapnik stylesheet has the National borders moved from coming in at z10 to coming in at z7. Now zooms to z6 show the borders as thin blue lines taken from the shape files, and then switch to OSM data at z7 using a slightly thicker purple line. Not all borders show, for one of two reasons - either they are not digitised or are not tagged appropriately. So, it would be useful if folk have a look at their own country/area at z7. Does in show correctly? If not: 1 - check whether it has been digitised. If not - is there a valid, non-copyrighted source for putting in the border alignment. 2 - check whether it is tagged boundary=administrative, admin_level=2. If not - change the tagging to that so that it may show. As a reminder, admin boundaries should be tagged for the admin_level that they are (at the highest level). Country/national borders are always admin_level=2. Internal borders should be tagged according to the suggested schema for that particular country. Details are on the wiki at: http://wiki.openstreetmap.org/index.php/Key:boundary which also explains the accepted way to tag for the countries on either side of the border. Cheers STEVE ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Filtering GPX tracks when they're good enough to make ways from but contain too many points
I've succeeded in uploading a large portion of my GPX tracks from Mexico South America and now would like to map out some of the highways. In many portions the GPX track (when converted to a data layer) is good enough for a way--the only sticking point is that there are way too many data points. I tried osmtrackfilter.pl with '--filter-reduce --out-raw-gpx' but the resulting file is actually bigger and doesn't seem to remove any points. Anyone know a filter that does a good job of achieving a large decrease in points without altering the shape of the track too much? These have got a lot of very straight portions and osmtrackfilter.pl was supposed to do a good job with those... Thanks, Beau ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Filtering GPX tracks when they're good enough to make ways from but contain too many points
Ah, excellent! Looks like this is part of 'utilsplugin', I didn't have that installed previously. :) I upped the value of this knob on the Einstein page to 250 and got good results (the default in the code was 50): simplify-way.max-error Thanks, Beau On Fri, May 23, 2008 at 1:36 AM, Stefan Baebler [EMAIL PROTECTED] wrote: Simplify way in JOSM does it (lowermost icon on the left toolbar, if memory serves me well). Stefan On Fri, May 23, 2008 at 9:14 AM, Beau Gunderson [EMAIL PROTECTED] wrote: I've succeeded in uploading a large portion of my GPX tracks from Mexico South America and now would like to map out some of the highways. In many portions the GPX track (when converted to a data layer) is good enough for a way--the only sticking point is that there are way too many data points. I tried osmtrackfilter.pl with '--filter-reduce --out-raw-gpx' but the resulting file is actually bigger and doesn't seem to remove any points. Anyone know a filter that does a good job of achieving a large decrease in points without altering the shape of the track too much? These have got a lot of very straight portions and osmtrackfilter.pl was supposed to do a good job with those... Thanks, Beau ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapnik layer of slippy map broken
Also just noticed this--just marked a tile dirty while testing a change and it came back without any of the data on it (except coastlines). On Wed, May 21, 2008 at 7:56 PM, Andrew MacKinnon [EMAIL PROTECTED] wrote: The Mapnik layer of the slippy map is currently broken. No map data is shown on recently rendered tiles (coastline data appears to be there). Please fix ASAP. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Huge batch of 1hz Mexico/Central America data
Excellent suggestions everyone, I wouldn't have known about tying up the
upload queue otherwise.
I may convert Richard's Perl to Python and upload using that with a
delay--once I get to somewhere that has faster internet access, that is. :)
Also, I hope OSM has a tag for the worst road on planet Earth because I
think I found it yesterday from the Belize border to Tikal in Guatemala...
Beau
On Sat, May 10, 2008 at 3:44 AM, Richard Fairhurst [EMAIL PROTECTED]
wrote:
Beau Gunderson wrote:
I've driven to Belize City from Seattle with a 1hz GPS logger and am
wondering the best way to upload the data to OSM.
You can see the route here:
http://www.bylandandsea.org/map
I've got it in GPX files that are each a day's drive long and also as one
giant GPX (180mb or so at current count).
Should I use the web upload feature or is there an easier way to do batch
uploads? Upload the gigantic file or all of the small ones?
Looks great.
Agreed with Lauri that you should avoid uploading the gigantic file
because it'll block the server for others.
You can certainly use the batch upload scripts that DT pointed to.
However, it would be kind to only upload five or so at a time, and wait for
them to finish before uploading any more. Uploading a lot at once blocks the
queue for others and can make you very unpopular when everyone is trying to
upload their weekend's work!
If you don't mind a bit of Perl, you can upload a GPX to OSM like this:
use HTTP::Request::Common;
use LWP::UserAgent;
$ua=LWP::UserAgent-new;
$ua-credentials('www.openstreetmap.org:80
http://www.openstreetmap.org/','Web
Password',$yourusername, $yourpassword);
$response=$ua-request(POST '
http://www.openstreetmap.org/api/0.5/gpx/create',
Content_Type = 'form-data',
Content = [ file =[$filename],
description=$description,
tags =$tags,
public =1 ] );
if ($response-code==200) {
# yay, success
} else {
# boo, failure
}
...from which a batch uploader (again, perhaps pausing every so often) can
be very easily constructed.
cheers
Richard
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Huge batch of 1hz Mexico/Central America data
I've driven to Belize City from Seattle with a 1hz GPS logger and am wondering the best way to upload the data to OSM. You can see the route here: http://www.bylandandsea.org/map I've got it in GPX files that are each a day's drive long and also as one giant GPX (180mb or so at current count). Should I use the web upload feature or is there an easier way to do batch uploads? Upload the gigantic file or all of the small ones? Thanks, Beau ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
