OpenStreetMap

escada has commented on the following diary entries

Post When Comment
Busroutes in Brugge 3 days ago

I have been collaborating with Jo a lot and I have a total different impression on how he handles existing data. I'm pretty sure he is willing to listen to your arguments.

Busroutes are not imported. Jo wrote a script that generates a proposal based on the busstops. Before uploading, he tweaks the busroutes.

Even when you disagree with his method, it would be in the interest of OSM to use the same version of the public transport tagging scheme in all of Belgium. I don't know whether this is a problem at this moment.

You won't find a lot of (Belgian) people with an interest in busroutes via your diary I fear. Almost all discussion is going on on the Belgian mailing list. This is by far the most popular way of communicating with other mappers.

Anyhow, good luck with your quest.

regards

Escada

Home Town Areal View 3 days ago

Impressive

ATMs in Belgium 3 days ago

I had the same reaction as aseerel4c26 . This looks like an import and some rules have to be followed in such case. Please join the Belgian mailing list to discuss.

regards

Turn lane (how to) 4 days ago

Since there are 4 lanes, and you positioned the OSM-way in the middle of the 4 lanes, there is no need to add placement:forward=left_of:1. A placement is only needed when the OSM-way is not in the middle of the real road.

Happy lane-mapping from another turn:lane mapper

Some basic statistics for the state of the map in Flanders, Belgium 13 days ago

I wonder why you say that the extra information of the road network is on the nodes ? As far as I know, road information goes on the way (maxspeed, maxheight, lanes, turn:lanes, destinations, etc.) or did I misunderstand that piece ?

Editing with Overpass and Level0 17 days ago

I could have written a program that called http://para.ms/relict/ (the old scheme) for all numbers between 1 and 999.999 and counted how many 404's were returned. And only proceed when the answer was 999.999. In that case I would have analysed each URL, not ?

As for the the fire hydrants, I want to stress that I only edited those objects of which I was the last editor. Even when they were simply moved by someone else, they were not included in the overpass query since the "username=escada" part would not return them.

I could not repeat that one, as I have added underground fire hydrants since then.

New Telenav Mapping Project: Dual Carriageways about 1 month ago

I usually have to do the opposite in Belgium. I have to change 2x2 lanes only divided by a white line that are mapped as dual carriageways to 1 way for both directions. This is needed when there are places where you allowed to cross the central line to access houses on the opposite side.

It's elegant they said. It will be eaiser to change street names they said. about 1 month ago

I'll admit that changing the wiki page right now is not a good idea. It's even difficult to start a discussion on how a good AS should look like at this moment.

Please note that I have added many AS in the past ( maybe >100), but given the current set of tools (e.g. the terrace plugin in JOSM), other people that do not keep AS up to date, the fact that the Belgian community decided to have addr:street on the nodes anyhow, people complaining about my tagging because KeepRight (?) did not recognized AS and insisted on addr:street, validation problems with streets with multiple names, POIs that repeated housenumbers, and maybe some other causes, I stopped creating them. AS just slowed me down without giving me something back

So for me there were more disadvantages than advantages, that's maybe a better explanation for my rethorical question above

I still like the idea behind AS, but don't see how the benefits hold when there is an alternative way that has to be supported (see my remark on Belgian convention).

It's elegant they said. It will be eaiser to change street names they said. about 1 month ago

I think that the vague definition of associatedStreet is also causing a lot of different unfulfilled expectations. I have read that that people put all street names and translations on the AS so they only have to change it once, some people still create multiple AS for each street segment. Other people hope that Nominatim takes the street name of city of the AS in case it is mentioned there.

Vincent now turns it in to a collection relation of all objects with the same addr:street.

In order the be useful, the definition should me much clearer, the editing & QA tools should give better support, more data consumers should use it, etc.

Since addr:street provides more or less solutions for all of this, why should I bother with AS ? (rhetorical question)

It's elegant they said. It will be eaiser to change street names they said. about 1 month ago

@Vincent de Phily, so instead of looking of 1 associatedStreet relation to change the name of a street, I now have to find multiple relations ? Isn't that a search ? The same thing you criticize for addr:street ?

And further there is no guarantee that the associatedStreet is complete, maybe there are "loose" address nodes that have to be updated as well. Without associatedStreets, a simple find will locate all addresses that have to be updated, with associatedStreets you'll never know. Some might have the addr:street tag, some get there address through the relation

Since you are in favor of associatedStreets, you might now whether there is a QA-tool that checks whether there are "loose" addr:street nodes and marks them as errors ? If this is not checked, the completeness of an associatedStreet-relation can be broken at any time, leading to a more complicated method to update simple typos in streetnames

Re:The order/thinking/philosphy/system of OSM tags;- Consistency about 1 month ago

I'll agree with you that amenity=drinking_water is a bad choice, and drinking_water_fountain would have been a better choice. I just assume that in the early days of OSM most people wanted to create a basic map and didn't bother thinking about tags in the way you do. So any value would do.

But, actually I also don't care to much about those values, as a non-native English person, they are somehow abstract anyway. And maybe that's the easiest to think about them. It's just a key=value pair.

I think it is far more useful to guide people towards the right tagging than to keep on discussing whether something is a "tourism", "leisure" or "amenity". I don't care when I want to tag a picnic table. I want to be able to search for it (in my native language) and the editor will add the right tags. Maybe even a set of tags. When I search for "drinking water fountain" and the editor adds "man_made=tap, drinkable=yes". Or even mangemaakt=waterkraan, drinkbaar=ja --- just to give you an idea how tagging would be in Dutch.

That kind of guidance more important than th actual value IMHO.

The tags are an internal representation. They might even have used "DW" for drinking water. The editors and the data consumer software should do the conversion to "natural" language.

Addressing about 1 month ago

In the town were I live you have to pay a fee when your house number is not clearly visible from the street. I thought that it is a requirement to have a house number on each building in Belgium, but according to my surveys, not everybody is following the law.

Addressing about 1 month ago

Nobody ever asked me what I'm doing. Perhaps because I walk four dogs and make notes on a GPS device. So people might mistake that for someone texting on a mobile phone while letting the dogs out.

Steve's Answers about 1 month ago

Thanks for sharing

The order/thinking/philosphy/system of OSM tags? about 1 month ago

I fear that the next overloaded key will be man_made. It seems like everything is going into that group these tags: street_cabinet, (water_)tap

Some things like windmill or watermill belong under building IMHO. It's pretty hard to tag a windmill that is no longer used for its original purpose, but as a house. Same problem for water towers

Public transport about 1 month ago

Meer informatie over de huidige manier van taggen vind je op http://osm.be/nl/content/mapping-public-transport-belgium

Learn-a-tag: highway=escape about 2 months ago

Very nice idea to highlight little known but useful tags. The area were I live is so flat I probably won't need this one soon :-)

Voting is bullshit about 2 months ago

@Warin61:

Re Voting: maybe most people on the tagging mailing list don't care enough for a water tap tag ? Maybe the discussion was only about having a consistent scheme and not about the feature itself.

I wonder how many people read the wiki pages. Especially when your mother-tongue is not English. Nevertheless, when 1 of the tags for mapping water taps would be documented and would mention all other tags that are in use, it might become the de-facto standard.

But when will people use 1 tag for water taps ? When iD and JOSM use the same preset. IMHO, you should not underestimate the power to push a tagging scheme by the build-in presets of those editors. So when you want your tag to be used, do not get involved in a voting process, sneak it in in the presets of the editors. :-)

Version Mismatch hatası about 2 months ago

Google tarafından İngilizce çeviri:

Ben bu tür soruları sormak için en iyi yerdir emin değilim. Eğer İngilizce anlamak, http://help.openstreetmap.org kullanın lütfen Aksi takdirde, diğer Turkisch mappers ile iletişim kurmak için kullanabileceğiniz bir posta listesi veya forum yoktur

https://lists.openstreetmap.org/listinfo/talk-tr ?

--- Original English text --- I'm not sure this is the best place to ask such questions. In case you understand English, please use http://help.openstreetmap.org Otherwise, isn't there a mailing list or forum that you can use to communicate with other Turkisch mappers

A little survey story 2 months ago

Warin61, thanks for sharing some problems of the Australian community. Of course the size of your country causes different problems compared to small Belgium.

Probably the quality of a good import is the same as those of surveys. My main critique regarding imports is that sometimes obvious wrong data is imported. Some of those imports have a manual verification step, but that is sometimes rushed, so non-existing buildings are imported or house numbers are placed in the dunes. That something you won't see with surveys.