@amm as more data is entered the number of contributors adding data and making changes will increase, although not at the exponential rates I keep hearing.

@robert mixing data sets is what google does best, they probably already have good tested to import OSM data and given half a chance I have no doubt in my mind at all they would have it imported before end of business that day.

@amm, even if PD is required after some event happens, what about all the existing data?

Also I was reading a good summary of this situation on slashgeo.org:

http://appdomains.slashgeo.org/article.pl?sid=10/01/22/1936242&from=rss

even if the data was suddenly given out as PD and mapmaker imports it, it will potentially lead to parallel mapping efforts as mapmaker users improve on the new data and existing OSM users don't use mapmaker to continue making their improvements.

In terms of reference tagging etc, did you see my custom highway page?

osm.wiki/Custom_Highway_Shields

A lot of touch screen phones have both GPS and accelerometers and in theory should work as well as this camera, just add some software, which is the sticking point, I tried to do something similar in the past but the math was too hard for me to comprehend.

Check out this page

admin_level=*#admin_level

If you tried all that and can't extract the data did you attempt to contact garmin and/or get your money back?

If you tried all that and can't extract the data did you attempt to contact garmin and/or get your money back?

OSM is basically an incremental process of improving over time.

Something is always better than nothing, but do better if you can do better.

But yea, from what I've seen the GPS on iPhones is one of the worst out of any mobile phone with GPS, not sure if this is a chip issue or antenna or what but there is speculation/rumour that a lot of problems AT&T gets blamed for is badly designed iPhone antenna etc.

What I don't know is if the iPhone can use a bluetooth GPS device, these are usually cheaper than buying a stand alone device, but adds more bulk either way.

@demi, updates are usually pretty quick, but browsers can cache the tiles, and tiles are only expired from the server cache if a node changes on the tile.

@Gnurfos it had me stumped for a bit, I'm just glad someone else solved it first :)

Geocachers have been hassled by cops in the past, geocaching.com.au issues a gimmicky geocaching license, maybe a license to survey issued by OSM-F that has a bit of spit and polish to it which can be laminated to make it look semi-official...

http://data.australia.gov.au was a fairly good move in the right direction in getting .au data out of government servers too...

What phone do you use?

I try to add as much applicable information as possible.

@HannesHH the US and Australia use big areas for postcodes, so it makes more sense to use a polygon (relation) in OSM than it does to tag each property since you can find out the postcode of a point using the polygon then. For more information on Australian postcodes see my post above.

If you are removing inaccurate data you might as well remove all the tiger data too while you're at it... Or better still approximate locations can be imported and locals can fix up the co-ords and then the better data can be given back to the EPA to benefit even more people.

While it's possible to distribute code like you suggest, I don't think the same can be done for databases, most just throw bigger hardware at the problem when it becomes a problem.

That's not to say we should keep doing things the same way, but at the same time I can't think of a better way to do it, I don't think storing files in a code repository is the answer either, databases exist for a reason, they're good at what they do.

@h4ck3rm1k3 OSM is already a monolithic DB considering people are tagging individual trees complete with botanical names. Some find that useful, like the person making a diary entry on orienteering the other day, but it is virtually useless for me.

On the other hand postcodes are very useful to me and I'm spending considerable effort finishing what Franc started by adding the missing postcodes into the system.

@balrog-kun why aren't they administrative exactly?

@aude why does it matter if the data isn't perfect to begin with, fix it up as you get people that have local knowledge, if you shouldn't import imperfect data why don't you just delete all the tiger data?

As for standard way to create them, perhaps you should look at what others are doing:

osm.wiki/Import/Catalogue/ABS_Data

Here's where we're up to regarding the import of Australian postcodes:

http://maps.bigtincan.com/?layer=00B000000FF

The ABS is the aussie equivalent to the Census Bureau in the US.

Australia Post hasn't publish a set of shape files either, but that doesn't mean others haven't made approximation areas that are good enough.

Also assigning them as address points, you must have to assign town and state and country informations to locations too then, but then you might as well add as_in tags too, or better instead use a boundary area for all the above and is_in can be calculated.

@h4ck3rm1k3 Yes there is a huge market for this kind of information, almost as much as for street data itself.

Also our postcodes in some cases cross state borders and so on I don't see why they'd need to be split up, it's easy to use relation boundaries to figure out what country, state, postcode and local government area a point or small area is.

Fair enough, and yes postcodes are different in the world, a single postcode in Australia can go from a suburb to areas many many times the size of the UK:

http://maps.bigtincan.com/?layer=00B000000FF