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

osm.wiki/Key: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

I should point I'm not implying an batch/automatic import, we are (slowly) importing the Australian postcodes by hand, OSM files were generated from shape files and then people can load these in JOSM and create postcode boundary relations using the information.

Although the main reason we're doing it manually is because other similar boundaries exist from the same organisation that released the postcode data, so boundaries for various administrative areas are shared, eg postcodes, suburbs, states etc.

If you have (approximate) boundary areas for the zip codes, why not import them as admin_level=8,boundary=administrative?

I came to the same conclusions some time ago, it's easiest to survey streets and map them, then go back for names, it's just too difficult to do anything else on your own.

However having said that there is a lot of data available with the map boundary data for Qld that should allow you to plot basic streets out for any Qld town, and then do the survey + street names at the same time.