oh, the fun with language we can have. how does your system work with these 100% legit towns in Germany and Austria?

https://www.openstreetmap.org/relation/941671 https://www.openstreetmap.org/node/240095754

this just as a friendly reminder, because one culture deems something inappropriate, another might think of nothing about the same word because it has a different meaning. other brilliant examples from this category are the Mitsubishi Pajero or DJ Bobo.

from all the occasions where i met reallife people involved with OSM there have never been many women around. actually, i am trying really hard to remember if i have met an active female mapper. ever. so getting a 10% recognition rate in a community award seems very much ok with me.

but then who cares if a feature was mapped by woman, man, alien or robot if it helps the user of the map to get to the right place?

pick the right bias and any community can be found to be skewed. i’d rather see women be better represented in the public via street names (love the map on that!) than in an anonymous group like mappers where gender is the least important feature to bring to the table.

@BushmanK .. i totally agree with you that having one dataformat (whatever it may be) across a dataset is better than anything else. no discussion required.

and me describing semicolon lists with the words “beautiful” and “elegant” was pretty much in direct response to your usage of the word “blunt”. both carry personal preference, but hey, that’s what makes us care. =)

anyway, as someone who works with large and sometimes huge sets of heterogenous data i gave up on “standards” and prefer best practice, because it gets things working. my reality – currently designing workflow & tools for 100k+ RAW images at a time with an inflow of 40TB+ per year – runs against my ideals of organizing and harmonizing that data.

call me a practical dreamer, i love clean data but that’s not what is happening. there will always be a bunch of edge cases, better make the tools to cope with them than to fiddle with old datasets.

2cts. ymmv.

@Carnildo may i suggest:
“Any” can be presented as the result of two “One” queries.
and “All” is finding the results that are on both of those “One” queries.

anyway, the end user should never have to worry about those details, since that is the job of the respective frontend. unless they want to, of course.

the difficulty with open projects is often that users get confronted with the real data although they don’t want or need to.

@BushmanK, maybe you are right about me. but then maybe not. who knows. what i do know is that people get all worked up about personal preferences like tabs vs spaces, emacs vs vim, linebased vs xml, and or even where to put a semicolon.

it’s all fun and games, yes, but in the end the important question is:

• does it work?

cuisine=italian;pizza
cuisine:italian=yes; cuisine:pizza=yes`

and – surprise! – both variants work, so the tools better be ready to handle them. because OSM is one of those projects that was started to create a solution instead of adhering to some theoretical standard.

funny. me thinks a semicolon separated list is a beautiful thing.

easy to parse and elegant to store. and since the end user has nothing to do with handling data from the database, well, it’s all flowers and sunshine everywhere.

and those that do data-handling, well, if they can’t cope with a semicolon list format, well, they should not touch that data at all. seriously.

for me the difference between restaurant and fast_food is what happens after you order your food:

restaurant: eat, then pay. fast_food: pay, then eat.

meistens sehr einfach an der Abbildung von Häusern zu sehen ob es sich um ein echtes Orthofoto handelt und damit nach Kontrolle der generellen Lage bedenkenlos abgezeichnet werden kann oder ob es sich nur um einfach Luft- oder Satellitenbilder handelt, die immer mit Vorsicht zu geniessen sind.

mir ist übrigens bei Bing noch nie ein echtes Orthofoto untergekommen.

in Österreich haben wir das Glück selbst im Gebirge korrigierte Luftbilder als Referenz verwenden zu können.

lovely tool. i guess you are using stats from a database analysis. how about counting the nodes associated to way/polygon objects instead of the objects themselves? this would totally eliminate the statistical jumps through splitting, merging and other operations.