escada has commented on the following diary entries

Post When Comment
Kleine veranderingen 5 days ago


welkom bij OSM. Hopelijk zien we snel je eerste bijdragen verschijnen. Volgens mij is het wel niet gebruikelijk om voor iedere individuele parkeerplaats een amenity=parking te creëren. Die worden volgens enkel gebruikt voor grote plekken waar veel auto's kunnen staan, zie ook de uitleg onder de wiki pagina

Misschien eerst eens navragen op het Nederlandse forum ?

alvast veel plezier met het mappen

Rückblick auf die FOSSGIS 2015 in Münster und Ausblick auf die Zukunft der FOSSGIS 11 days ago

Thanks !

Rückblick auf die FOSSGIS 2015 in Münster und Ausblick auf die Zukunft der FOSSGIS 12 days ago

it seems like all your links point to the same presentation

Rückblick auf die FOSSGIS 2015 in Münster und Ausblick auf die Zukunft der FOSSGIS 12 days ago

The actual link to Claas Leiners presentation is

Improving the OSM map - Why don't we? [3] 18 days ago

I think they should be mapped as survey points

Improving the OSM map - Why don't we? [3] 18 days ago

I've contacted to creator of the man_made=1417-32 node. Asked what the objects represents, and proposed to improve the tagging together. Hope (s)he understands English.

I've met several people that do not know about the existence of the mailing lists. With some luck they find the help website. I wonder how many people don't know about the community around OSM.

I've suggested elsewhere that it would be nice if the editors (iD, JOSM, ...) would show a help popup depending on the region you are editing. Each country could then add a short message with the best way to contact other mappers, be it email, forum, Facebook, irc, ...

Improving the OSM map - Why don't we? [2] 20 days ago

Those bicycle repair stations where recently imported by Brice Nesbitt (if I'm not mistaken). I assume the import didn't had more details. It's up to the local mappers to add more detail. This is always the case in OSM. We start with the basics and later iterations will add more detail.

On the other hand, it's probably save to assume that such a repair station has all the basics to repair your bike. So why bother adding more detail ?

I'll agree with you on the recycle container, all the no's don't give any more value.

Improving the OSM map - Why don't we? [1] 21 days ago

On one hand, it is better to have one tagging scheme for 1 feature. On the other hand you have just showed how easy it is to retrieve data using the different tagging scheme's. So you might wonder why it is a problem to have different schema's in place.

Maybe we should just develop a query language that can deal with different schemas and synonyms.

Busroutes in Brugge about 1 month 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.



Home Town Areal View about 1 month ago


ATMs in Belgium about 1 month 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.


Turn lane (how to) about 1 month 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 about 1 month 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 about 2 months ago

I could have written a program that called (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 2 months 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. 2 months 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. 2 months 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. 2 months 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 2 months 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 2 months 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.