You should probably drop by on the Belgian mailing list (osm.wiki/Mailing_Lists)

Jo (Polyglot) is active with maintaining bus routes, he uses data from de Lijn. I guess cooperating would be best, else you start destroying each others work.

Thanks for the contributions, it’s looking good so far.

I do notice that you added an already existing POI.

Here you see a building (added 1 year ago) with a restaurant tag and cuisine “chicken”, however, no name osm.org/way/225494196

And you added the following point, in the same building, with the name Chick-fil-A: osm.org/node/3369588937

As both chicken restaurants are so close to each other, I guess it’s pointing to the same restaurant. Since there should only be one representation of it (so we can count the number of restaurants per city f.e.), one of the two should be deleted, and tags merged.

You may notice that it’s not uncommon to tag POI on buildings. When you tag it on a building, there’s added information (f.e. the size of the restaurant, a logical connection to the different entrances, …). However, if a building isn’t completely used by that POI, it should probably be tagged on a node.

But thanks again for contributing valuable information.

Do you know that there’s a lot of discussion whether parcel data belongs in OSM?

First of all, there’ the “ground verification” that’s very hard with parcel data. We need to trust the governments that give us the data.

Secondly, parcel data updates a lot (parcels get split or merged). It’s even hard to maintain this in the governmental database, so it’s very hard to do this on OSM.

osm.wiki/Parcel

There are different factors involved when it comes to precision. I isn’t enough that your sensor is precise.

First of all, it matters how precise you hold the device. If you have a 2cm accurate sensor, it’s rather easy for the human hand to wiggle 2 cm, and thus cause an extra precision node. In fact, I see that in this data, some points are even there when there’s no wiggle at all (or something lower than we’re able to represent in OSM).

Then you also have the changing nature of things. When grass lives in a good environment, it will take several cm of the sandbox per year. If the grass doesn’t grow well there, more ground will turn into sand over the years. So if you map something natural up to 5cm precise, it will only be true for a year or two. It’s even worse for water, which may change on a daily basis.

Thus, to answer your question: I don’t think OSM will ever become as precise as the data mapped there. There’s a natural limit to our precision. Any data we add beyond that natural precision will just give us the fake idea of improving the data (and it puts a burden on the data customers).

The simplify way algorithm uses (most likely) the Douglas-Peuker algorithm. That algorithm is clever enough to not just evenly space nodes along the line, but it removes the nodes that influence the shape as little as possible. This is done by comparing how big the area difference is when you delete or keep a node.

As such, the end results are that it deletes the nodes that don’t change the shape, but it keeps the nodes close enough in a sharp turn. Of course, finding the right precision value is a bit of trial-and-error, as it differs per case.

Also, it looks like most of the features he added were already present in the data, but just not tagged with landuse=*, so they weren’t rendered.

Ugh, it’s even worse than that, he even tagged all nodes: osm.org/node/3367453367

Since he wants high-precision data, the default settings for simplify-way are a bit too coarse. So someone who knows to enter finer settings, that would be very nice.

And of course, null-angle or almost null-angle nodes should be deleted, but sharp turns can still benefit from a node every 30 cm. But this is something algorithms (like the one in simplify-way) do rather well.

AFAIK, it’s a tendency to use source=* on changesets, not on objects (that was the old habbit).

Sadly, overpass doesn’t offer changeset-based queries, so that wont be possible. But I guess the real number is a lot bigger.

Although the individual results are interesting, I guess they become more interesting when you compare different regions indeed.

If you would scale the graphs for different regions to the same total, you’d be able to see when evolution happened, or if certain regions were boosted by the availability of certain sources (dataset, pictures, …).

Btw, I wonder what that drop in 2009 is (for the second graph). I don’t see any obvious reason why nodes would have been deleted then (licence change was only in 2012), nor do I see a reason why nodes would be replaced with areas (release of Bing imagery was only at the end of 2010). It’s also strange that there’s no drop whatsoever visible in the other graphs.

Sorry, I don’t speak Italian, but I should warn you.

Even if it’s allowed to import something, doing it right isn’t easy. You need to have a longer experience in the osm community, and have seen some failed imports, before you can do your own successful import.

My definition of an address was just addr:housenumber, as there are still a number of associatedstreet relations around.

And my numbers seem to match the total on http://qa.poole.ch/addresses/

In any case, I’m more interested in the evolution and regional differences than in the absolute numbers.

Well, if the errors are systematic for one street, I guess you can mention all errors in one report. The reports are read and processed by humans, and not by computers.

And for me, the terracing tool seems to take the tag from the building outline. So if the ouline is tagged with building=house, all houses will be tagged as that.

Node vs way ratios seem about equal between different provinces and Brussels. Next to that, Brussels is fully urbanised, which makes drawing building outlines and assigning addresses to buildings more difficult. So that number of address nodes is about expected I guess.

Excusez moi pour mon français, ce n’est pas ma langue maternelle.

Des problèmes avec les images Bing, c’est qqc qui ce passe régulierement. C’est parce-que MS a acheté des nouvelles images, mes des nouvelles images ont une qualité plus basse. Soit les images d’haute qualité sont trops chèr, soit ils sont pas disponibles.

C’est possible d’ajouter une version d’images Bing avec zoom limité. Donc ça veut dire qu’apres la qualité maximal des images, on commence a enlarger les pixels.

La solution depends de votre editeur. En JOSM, c’est possible d’aller vers Imagery -> Imagery preferences. En bas, en voit des URLs des images utilisés. C’est mieux que vous copiez la ligne de Bing dans une version nouvelle.

Pour ça, aappuyez le bouton “+TMS”, et mets

bing[17]:http://www.bing.com/maps/

dans point 3 (verify generated URL). Ici, j’ai choissi le zoom maximal de 17, c’est possible que vous a besoin d’un zoom different. Mais ça depends de votre region exact.

Pour nom, prenez qqc come “Bing a zoom limité”.

Comme ça, on peut choisir entre les images avec zoom limité (limité jusqu’á niveau des images recentes) ou des images normal, avec zoom maximal.

Quand le zoom 17 n’est pas correct, on peut modifiez le URL direct, mais on doit re-ajouter les images dans les layers de JOSM pour applicer les differences.

J’espère que ça marche. Si tu me dites dans quel region tu travaille, je peut aussi chercher le zoom correct.

Next to users forgetting to copy the tags, there are also users that will copy the tags when they see creating a new object. Some newbies might think this set of tags is necessary, they adapt or remove the ones they understand (name, address, phone, …), but it’d likely they don’t know about the id. Then you end up with two objects with the same id.

The question if an object is moved, or deleted and recreated is indeed a valid question. And IMO, it completely depends on the data user. Some data user might want a new entry when the operator changes (because the bills have to go to a different address, the service might be different, …), others depend on the name, or the location. It’s obvious that it will be impossible to include data like that in a sane way.

Maybe you know the permanent id feature of overpass? osm.wiki/Overpass_API/Permanent_ID It’s versatile, as it needs to fit all data users, but that also makes the interface less user friendly. If you want to use it for something custom, the are possibilities to give it a better interface.

When you really want to change osm, I would do it at the meta-data level, not at the tags users can see. It would need an update to the api version, and many editors will need to be altered, but it’s possible. Just like you currently have version information in the data, you could have info from which historical object the data comes. The editor then tries to see which object replaces which, or which object is derived from which, and adds it to the metadata. Typical operations include splitting and merging of ways, and replacing a node with a polygon (which is harder to discover). Being able to see that the history of one object depends on a different object would also make vandalism detection and reverting easier.

Sorry for speaking English, my German isn’t good enough.

Do you know about existing in-browser rendering projects? There’s KothicJS, and Mapbox is also developing some js libraries. These work with quite good data formats (a lot faster than plain osm xml), and also pre-filtered data, but it’s still slow for certain hardware and browsers.

Or just try overpass turbo with some big resultsets. It makes panning and zooming a pain when you want to display a few 100 points.

So those things are tried, and need some time to develop.

Next to the slow browser rendering, you still need a server that filters the data (when you zoom out to see the world, you can’t download and view the entire database). That filtering needs to happen based on a stylesheet (on what level do you want to see which roads?), and the filtering will also be slow (imagine filtering the entire world just to extract to motorways). So the filtered data needs to be cashed.

So in the end, you still need a server that processes all incoming data, and that has to redo the work when rendering rules change. Exactly like a rendering server.

I’m not saying that the things you mention are impossible, I’m just saying that they have been tried, and either are found too difficult or too slow for now.

I guess for wind, generator:source=wind_turbine might be too general.

There’s a big difference between wind turbine size, the number of vanes, or even strange shaped like these examples: http://www.quora.com/What-is-the-most-efficient-design-for-a-wind-turbine

It’s not a simple question indeed. Thinking about tags is thinking about categorizing, which requires you to look into the problem first.

Some of those things you mentioned fall under healthcare. The difference with traditional healthcare is more in the research. Treatments developed by recognised healthcare researchers (like universities) normally do more rigorous and peer-reviewed studies. While the alternative healthcare might also work, but that is often disputed due to the lack of research, our due to non-conclusive research. Alternative healthcare typically doesn’t deny existing healthcare, but offers additional, unproven, treatments. For this group, healthcare=alternative must work good enough (perhaps with some sub-tags to clarify the use further).

For the other things (f.e. cartomancy), it gets interesting when you read things about magic (f.e. on Wikipedia). You’ll see that the line between magic and religion is small, and there are many definitions about it. Both have rituals and symbols, and both claim that theoretically impossible things can happen. However, IMO, the most clean distinction is that magic is demanding something, while religion requests something. F.e. a witch casting a spell to help you is magic. It’s the witch that has the power, and if the spell fails, it’s because the witch didn’t do it well. While a priest can pray to help you, but that’s only a request which God can deny. Given the similarity, maybe a similar tag should be chosen. F.e. amenity=place_of_magic. Together with some sub-keys, this might work fine.

Thanks for your contributions.

About the distinction between primary, secondary and tertiary, that classification can’t be decided on the looks of the road, but it needs a broader view to classify it. The difference mainly comes from the difference in importance. Primary roads connect all big cities, secondary roads connect smaller cities and towns, and tertiary roads connect villages to a city or town.

In places where unpaved roads are common, you also shouldn’t just use “track” for any unpaved road. A track is a road for mainly agricultural use. If a road to a village is unpaved, its classification should still at least be unclassified.

So after all, it’s hard to get the classification right when working on a single tile. The most important thing is to trace the roads, so the network becomes visible on the map, and the roads can be re-classified in function of the complete network. Osm is mostly an iterative process anyway.

About those U.N. maps, no, you can’t use them without special permission. The U.N. often gets the maps or data from national or local governments, but that means the local copyrights apply. And in many cases, it’s very hard to figure out if it’s possible to use our not. In most cases, it’s better to look out for US army topo maps. Those are normally more detailed (even if they’re older), and are always legal to use (everything the US federal government makes falls under PD).

I don’t like AS relations, but for other reasons.

First of all, it’s not clear what an associated street is. Is the street still associated when it crosses a municipality border, or when different parts get different postcodes? Do cycle lanes belong to it? And what about driveways? That relation is trying to bring structure to something that doesn’t have a unified structure on it.

Secondly, it makes “upgrading” addresses from points to buildings hard. When only tags are used, it’s quite simple to copy the tags from the node to the building, and erase the node. When relations are used, there are more actions needed. You still need the copy operation to bring over the house number (and perhaps other tags s.a. shops or amenities), but you also need additional work to search for the right relation in the list (which can become a long list), and add your building to it.