OpenStreetMap

Sanderd17 has commented on the following diary entries

Post When Comment
ATMs in Belgium 6 days ago

Sometimes, banks don't want that you copy it. They're sometimes afraid that you'll copy the data, and then, after a few years, it's outdated but people still use it.

When someone searches a bank using outdated data, he can become frustrated when the bank isn't there anymore. So some banks want to be protected against that, and try to limit copying.

So that's why banks might be reluctant. However, surveyed data can have the same problems, and banks can't stop us from surveying. So their sort of protection isn't too clear.

Note that this also counts for other shops, it's the sort of answer I got a few times when asking to use a shop DB. I had to make sure I kept updating it in OSM (and sign a contract for it). But of course, I couldn't guarantee that.

About it being an import or not, I think, as long as you check every thing you add via aerial imagery, it's more armchair mapping than an import. So I'm certainly not against this practice.

Busroutes in Brugge 6 days ago

Hmm

I also mapped a few bus routes in the past (but I found it hard to map a complete town), and AFAICS, Jo did leave these stops where I put them. So it looks like he did treat the existing data with care.

There were other problems though. Like some inaccurate positions for bus certain stops he added. But I had no idea there was a problem with data being outdated.

Of course, when a bus route is deleted, there's no existing data, so I guess Jo just imported that.

Busroutes in Brugge 6 days ago

You should probably drop by on the Belgian mailing list (http://wiki.openstreetmap.org/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.

First Contributions 7 days ago

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 http://www.openstreetmap.org/way/225494196

And you added the following point, in the same building, with the name Chick-fil-A: http://www.openstreetmap.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.

Mapping Parcel Data in Canada 7 days ago

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.

http://wiki.openstreetmap.org/wiki/Parcel

It's not because you have accurate data that you have to upload all of them in OSM 7 days ago

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).

It's not because you have accurate data that you have to upload all of them in OSM 8 days ago

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.

It's not because you have accurate data that you have to upload all of them in OSM 8 days ago

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.

It's not because you have accurate data that you have to upload all of them in OSM 8 days ago

Ugh, it's even worse than that, he even tagged all nodes: http://www.openstreetmap.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.

Mapillary data usage on OSM 11 days ago

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.

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

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.

Importazione massiva di dati 19 days ago

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.

Address evolution in Belgium 23 days ago

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.

Address evolution in Belgium 24 days ago

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.

Address evolution in Belgium 24 days ago

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.

DEUX VERSIONS D'IMAGERIE SUR BING 25 days ago

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.

An idea for making it easier to link external data to OSM 26 days ago

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? http://wiki.openstreetmap.org/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.

image format 28 days ago

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.

Power Generation tagging, and a rather neat way of tagging wind farms 29 days ago

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

Holistic/esoteric centers about 1 month ago

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.