I asked my dad (he uses AutoCAD) to convert it but the download will take him probably about 2h. He told me you can use ACME Cad to convert any version of .dwg to .dxf and it's downloadable for free, if you have ms Windows (I don't), here's some download page:

http://download.cnet.com/Acme-CAD-Converter/3000-18496_4-10431995.html

I don't think postcode/zipcode areas are administrative divisions like regions/states/provinces/counties/municipalities etc, they're an aid to the postal service and are not part of the administrative hierarchy of different admin_level's.

I'd suggest boundary=postcode or some such.

Turns out changeset 3M is a scripted upload of NHD data, no fun :P

Someone on IRC noticed today (halloween) that chanegset 666666 was just a year ago, now we've had five times as many changesets this year than in all the time before.

Assuming the .osm files you get from shp2osm have the xml formatted nicely, like what JOSM produces, you could remove zero tags using grep (that's why it needs to be formatted nicely so each tag is on a separate line), so you would grep for something like "key='ele' value='0.0'":

cat converted-shp-file-before-upload.osm | grep -v "key='ele' value='0\\.0'" > file-stripped.osm

Before upload because otherwise you would need to also add the action="modified" tags to every object modified. The -v inverts the matching so that matching lines are skipped instead of non-matching lines.

You can also do such things with JOSM and its search function, but scripting it seems easier.

(I'm in east Europe.)

Something like the interactive data layer displayed by default would be really great, unfortunately it's a pretty big technical challenge -- the javascript engine in the browser can only hold so many elements in memory and no more and it's easy to clog the browser this way. However if intelligently designed it could work -- we would need a hierarchy of importance of objects (like the one in mapnik's osm.xml) so that obejcts relevant to the zoom level get loaded, and we would need to set a sensible limit for the number of objects that are "interactive" at any given time (this would probably be no more than 20 or 30). We would need to teach the tile generator to simplify complex polygons, and we would need make small changes to OpenLayers to support the graphical side of it.

Two weeks ago I implemented a wikipedia overlay for mapnik where I had to tackle most of the same issues, but I've not set a hard limit on the number of object. http://www.openstreetmap.pl/wp (Firefox-only)

Oh another thing I noticed is that where buildings touch each other (share an edge) they would normally reuse the same nodes but in this data they have separate sets of nodes.

(The revert changeset is 2792386)

Looks like the revert worked! Hopefully nothing useful was removed :p

The imports I've done so far were not from .shp files so I had to use a custom script to convert (in Python, even though I can't say I know python). Then I upload using another python script (similar to bulk_upload.py) and that's where I can tell it to start from a given point instead of from the beginning.

Some more comments on the buildings imported:
* They look really cool, I think that's going to be useful especially with the elevation and storeys info -- one could potentially build some 3d models now.
* There are buildings with addr:housenumber=0, ele=0.0 or storeys=0.0, I think these tags can be safely removed where they're zero, apart from the names issue you mentioned.

Hi, before you start removing the fallout from the crashed upload by hand, try simply reverting the changeset that had failed, if no edits were made on top of it, it should be pretty easy. Or you can tell me which changes need reverting and I'll do that as I have the all gear set up for this.

Also instead of restarting the upload you could either edit your upload script to continue from where it had left off (that's what I normally do although I realise each script is different) or download the state after the crash from OSM and use the existing nodes instead of creating new ones by matching coordinates.

I recommend splitting long ways at 200-300 nodes and not coming near the 2k limit, makes working with the data easier.

So here's yet another way of tagging raceways: osm.org/?lat=50.9605&lon=20.53909&zoom=17&layers=B000FTF :)

highway=racetrack is supported by mapnik but not Osmarender.

Suerte! A mi tambien me viene mucho mejor el editor java (aunque sea en java y me ocupe toda memoria ram)

When a street has two names or two forms of writing the same name I usually just add a alt_name=Whatever so that it become searchable under both names -- even if one of them is clearly incorrect let users search by this name. This happens also in Spain and elsewhere that there's a new and old form of writing a name or just a wit of whoever decided on the labels.

I don't see Zartbitter's message as arogant, he just states the facts. You shouldn't judge OSM as a project by the rendering at www.openstreetmap.org, it's one of many renderings and it's one of the less important parts of the project. And certainly don't judge the usefulness of your mapping this way. Think of the navigation software and search engines rather, they'll find your POIs.

Also, thank you for your mapping, it's definitely not useless.

I, too, think this data should be imported if possible -- there will be a percentage of people opposing to loading such amounts of not-so-crucial geo data on the mailing lists when it's put up for discussion but in the end the storage should not prevent us from making detailed maps. If the property boundaries are not imported from an official source, eventually local mappers will recreate the same dataset, just with poorer quality.

Yeah - the point is to find the perfect balance between decompression/compression time and IO time. For disk IO the balance is different than for network IO.

I was talking about disk IO here, i.e. when you have the snapshot on your disk. For network IO, using lzma would probably give the best balance, because it generates the smallest files.

People are so mean, right?

The coordinates are iirc rounded to 0.15 deg, which is rather poor for many purposes but still more useful than no data.

I don't speak Hungarian, but if someone translates the main website then I can pick the strings from there. openstreetmap.hu only has about 3 translatable strings so it would be a quicky :-)

Bienvenido!
Si te refieres al tiempo que demora la capa mapnik en la web principal en actualizarse, es entre una hora y dos horas (porque se usan los archivos con cambios que se generan a cada hora) para los cambios mas basicos, pero hay algunos tipos de cambios, en particular los que contienen relaciones, que solamente le llegan a mapnik los jueves cuando se re-renderiza todo. O asi es como deberia ser.. en la practica muchas veces demora dias o semanas. Si necesitas que sea mas rapido, en la otra capa, la osmarender puedes solicitar que se actualice alguna parte cuando tu decidas, usando informationfreeway.org

Thanks for the suggestions, as for pbzip in case of the dual core CPU it could give at most 2x speedup which would still make the compression the bottleneck in the whole process (but note that the second core isn't idle either, so perhaps less than 2x). If the benchmark I linked is to be trusted, you would need to be running pbzip on an 8-or-so-core system for it to be able to compete with gzip in terms of both compression and decompression.

(I haven't recompiled the bzip or gzip per se, but I'm running this on a Gentoo system and I let the system "build itself" with what it thought was good, I set the CFLAGS quite aggresively including -O3, -march=athlon64, -msse, -m3dnow)

And as for LZO: oooh I think that's what I was really looking for when I googled LZMA yesterday (didn't remember the exact name). I'll try it on one of the planets this week and report back.

Hey,
I've just set up openstreetmap.pl and I permitted myself to copy most (all) of your design which looks very slick. I'll be modifying it from there on as time permits, but at the moment it looks almost identically, just the site is in Polish. The placement of the controls lower on the screen was a bit of a challenge to me too and I've only found a quite poor solution so far.

Good job mapping Chile!

Cheers
(sorry for the double post.. wanted to post it as a comment)