OpenStreetMap logo OpenStreetMap

Changeset When Comment
35716874 over 9 years ago

Sorry for that. But it would make sence to add a hint to the engl-wiki to give others the chance to know it. Can you do this?

34256932 over 9 years ago

pop. should be number !
osm.wiki/Key:population

35387180 over 9 years ago

I'm working on it to find a good solution.
But beside this: 99% of is_in_iso (even outside USA) is not from me, so others also need it. I think we should start a broader discussion about all is_in* keys.

35676822 over 9 years ago

connecting the language versions of same wikipedia articles was the first mayor task of
www.wikidata.org
Therefore we can trust the lanuage mapping, which works good since >1 year.
Having redundant information is only blowing up the database.

35671561 over 9 years ago

You are right. But changing the rest of the world would be more complicated than only one nation. But I agree, "iso3166-2" would have been my favorite. But for machine reading its better to have the same key worldwide.

35676822 over 9 years ago

osm.wiki/Key:wikipedia
citeation from ther:
"In almost all cases, a single wikipedia tag as described above is sufficient."

35387180 over 9 years ago

there are megabytes of key="is_in" having long values, and only kilobytes of is_in:iso*, so why it is so urgend to remove it? I would still like them, but not adding them.
The problem is at the moment: questions with big results are still very slow and often aborting.

35652885 over 9 years ago

I just wanted to remove place=country, but was not sure what the original author had in mind. I thought about fixme, but you are right it was only a half fix. Sorry

35387180 over 9 years ago

Yes it seems to works.
But now I suffer on:
all place=city && population>10000000 on full planet. Thanks alot, Alex

35387180 over 9 years ago

This gives all nodes place=town in "Brandenburg, germany", I think..

http://overpass-api.de/api/interpreter?data=[out%3Ajson]%3B%0Aarea%283600062504%29-%3E.searchArea%3B%0A%28%0A%20%20node[%22place%22%3D%22town%22]%28area.searchArea%29%3B%0A%29%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B

35387180 over 9 years ago

the id of border (way or relation) is known to me. perhaps this makes it easier for you.

35645813 over 9 years ago

wrong title: fixed bad postcode

35387180 over 9 years ago

many thanks in advance. Alex

35387180 over 9 years ago

Could you please tell me how to do it automatic (from script, eg. using wget).
The task should look like: get all key="place" from inside iso:DE-HE.
I dont want mouse interaction because we have >1000 different ISO-regions on this planet. Thank you for your help.

35387180 over 9 years ago

https://taginfo.openstreetmap.org/keys/is_in%3Aiso_3166_2
tells 26463 uses for this key.
Yes this data could also be derived from other data, but more complicated.
But I would first remove is_in:continent, -state, -country, is_in, etc., and still keep this short one. I you process 1mio POI it takes much longer to find out where you are, than having it as a tag.
I hope you can live with this.
Thanks, Alex

35248197 almost 10 years ago

(sorry for the delay, I was in holidays.)
the source of fixing it is mainly the OSM-wiki + TagWatch (e.g. population=20,000 to 20000) and OSM database itself (is_in:iso, is_in).
I try to make OSM data easy useable (e.g. no comma , ; inside integer values, or pop=20 habitants, means no useless unit). This should be fine.

35203565 almost 10 years ago

I did this one evening. And I only did easyly to find ones (e.g. 9x "9" = 999999999).
1. If limiting datasize is no point and increasing readability by computers, why the many wikipedia:de,:en:fr:es:etc have been worldwide changed to wikipedia = en: ?
Having identical keynames, and same value-string for same meaning should also be pushed more.
2. Averaging of 10001 x GPS (delta = 10m) gives 10 cm final accuracy only (if all people carry their GPS in same height and walk the identical way). And even then: each one in sub-mm gives no advantage.
3. We have many values with more than Angstroem (1E-10m), this is below atom size.
4. Obviously wrong ele-tags, like ele=building, ele=10000, ele=-444,
or obviously bad formated strings like 1.20000000000, 1.300000000001, 4.999999999999, 2.3456789E-5
make no sense to keep them.
5. I added hundreds of ways, buildings, etc, and many GPS-traces, so I think it is unfair to say "you should add something to the project".
6. natural=tree, ele=1.23456 means which point of the tree?
7. If it has been hand carried or from inside a metal-car, noone will ever be able to get much better than a full meter.
8. If a road is off by 1m (vs. satelite) it means it is of by 10m in elevation!

35203565 almost 10 years ago

Hi Anders,it is not possible today to measure more than 1mm (H-Star) accuray with GPS in Lat+Lon. And Elevation is off by Factor of 10).
Also other methods have are happy with 1mm in best case. Normal GPS is off by about 10 meters in height !
Additionally the surface is not that even.
Even good streets have valleys of 1mm per meter! And natural ground is moving up and down (temperature, humidity, geological) in this range.
So why this sub centimeter precision should be useable?
(in physics we do alot of precision discussions)
osm.wiki/Accuracy_of_GPS_data

35204916 almost 10 years ago

about 300m around this are many strange ele=* !
can you check this?
I dont know this area.

35185437 almost 10 years ago

Wenn du wieder mal etwas findest: ich suche nach unbrauchbaren oder flaschen Daten.
VG, Alexander