Sanderd17 has commented on the following diary entries
|Placeholder||3 days ago||
Are those cranes randomly generated on construction area?
|email rejected||12 days ago||
OSM is not a shop, we don't sell maps. OSM is just a volunteer organisation that gathers geographic data.
It is possible (and legal) that some people transform the data into a nice map they can sell. But then you should contact those who make the map, instead of us, who only gather the data.
|2015 Mariana dam collapse (help Brazil)||17 days ago||
Just a note: watch out with aligning to bing imagery. Bing doesn't always have the correct alignment, certainly not on uneven terrain (which is usually the case near riverbanks).
|Distribution of locales (languages) among HOT tasking manager contributors||18 days ago||
What we speak, or what we read?
I speak almost 100% Dutch, but I normally set all my software to English. Not because Dutch translations are that bad, it's just easier to communicate with others when using the same terms. I used to look up term after term when submitting a bug report, but now I don't have to do that anymore.
|Proposal: Sunset ref=* on ways in favor of relations||22 days ago||
There's a conceptual difference between the European refs and the US refs.
In Europe, it's custom that an official body gives a road one and only one ref. The ref is only used to name the road, but with numbers as they lack some naming inspiration. This means that refs don't have to be continuous. F.e. a national road can stop when it meets a ring-road (who have their own ref system in many countries), and start again on the other side of that ring road. Expressing this with route relations would be silly: routes are supposed to be continuous, our refs aren't.
The fact that the EU also gives their own ref to the road doesn't change that principle. They use their EU ref to name the road, while nations use their national ref to name the road. In most cases, the nation prefers to keep using their refs and their refs only. In other cases (like Belgium), the nation adopts the European reference system, and is phasing out the legacy national refs where EU refs can take over (that means sings get replaced, maps get updated, ...).
This is completely different from route refs, where a route is bound to be continuous, thus some roads belong to multiple routes. The route reference system you mention is indeed more similar to PT, bicycle and pedestrian routes than to the European ref system.
The difference is IMO big enough to need two ways of tagging. So I agree with Richard: you can go ahead with the US (though the US community should decide on this), but the schema you propose won't work very well for Europe.
|Units in OpenStreetMap||26 days ago||
It's easy to unify measurements when you get the units. It's hard to estimate the units when you get the unified measurements. If an editor wants to display the originals, but only gets the SI units, then it will have a tough job (and quite likely show mistakes in some cases).
So in a typical case of being lazy, the easiest method should be implemented.
Also note that it's not only about the two main editors, there are also numerous other apps that display and allow edits to tags. Think of the general OSM site, vespucci, and even apps like OsmAnd.
I do agree with SK53. It would be nice to have a standardised database (or maybe just a program to create such a DB). It would allow complex things, s.a. having defaults per country. (lit=yes should really be a default for Belgian roads f.e., around 98% of our roads are lit). But this doesn't belong in the main database.
|New Telenav tool: Fix missing and wrong one-way streets||29 days ago||
Nice tool, though I'm seeing certain issues.
First of all, in my area, most of the issues found seem to be very short road pieces, only a few meters long, part of a big road. They're split up because of route relations, or changes to tags like speed limits. Is there something that makes detecting these small segments easier? See most issues in this area: http://improve-osm.org/trafficFlowDirection/#11/51.0008/3.0933
Secondly, do you take dates into account? Traffic layouts change often, and streets might change their oneway direction. Perhaps it can be detected by seeing that from a certain date on, 90% of traffic rides in one direction (if the sample is big enough).
|Mise à jour cartographie - Artois / Flandres / littoral||about 1 month ago||
Je suis aussi Flamand, mais de la coté Belge ;) Excusez moi donc pour mon français, ce n'est pas ma langue maternelle.
Je visite parfois les monts des Flandres, mais je reste à la coté Belge normalement: Kemmelberg, Monteberg, ...
Peut-être je peux vous aider avec un link vers le wiki: http://wiki.openstreetmap.org/wiki/Mountain_biking Cette page explique certain tags spécifique pour le VTT.
J'espère que vous vous amusez avec le découvert des chemins nouveaux, et que OSM s’améliore dans le Nord.
|Efficiently adding direction=* to highway=give_way/stop||about 1 month ago||
Very nice work you're doing.
Your workflow is ok, but you won't get anywhere on your own. You should probably try to get it in as many editor and QA apps as possible.
Also, the style could be improved. AFAIK, it's possible to rotate icons to the way orientation, in which case you can make the arrow+stop sign rotated in the right direction (then you don't need to show the way direction). See https://josm.openstreetmap.de/ticket/10217
This should make more mappers use this tagging, and in turn help the routers. I'm looking forward to that.
(note that some types of traffic light tagging could use the same direction tag, so you could apply the rendering there too.)
|Open Question about tehnical issues around prepping boundaries SHP to Osm schema||about 2 months ago||
But afaik, transforming an SHP into OSM data isn't the most difficult. The most difficult is doing the quality checks before uploading, and making sure that the data is blended in nicely with the existing OSM data (connects to neighbouring boundaries, etc). For this, you should really follow the import guidelines: http://wiki.openstreetmap.org/wiki/Import/Guidelines
|What happened to the city of Sacramento?||about 2 months ago||
It looks like nobody ever created that boundary. No idea why.
|Grass&Green:How does it work?||2 months ago||
If you plan to include Belgium, you'll see very strange stuff. We've had someone mapping lots of landuse, but mostly just aiming to reproduce the colour on mapnik.
He has drawn forest areas around single treetops (resulting in 300+ forests in a town of only 80000 inhabitants), and also making really bad mistakes like this one: http://www.openstreetmap.org/way/89503452
But mostly just wrongly tagging meadows and parks as landuse=grass. Like http://www.openstreetmap.org/way/298526045
I tried fixing it in the past, but just ended up frustrated.
|Ice Cream||2 months ago||
Hmm, ice cream vendors aren't real shops. Some offer places to sit, and in any case, you're supposed to consume it rather quickly (unlike typical shops where you take the goods home before using them).
So I can see why amenity is preferred over shop in this case.
But mapping those is a bit tricky though. At least in Belgium, many ice cream vendors become waffle vendors during the winter months, or combine the two through the year.
amenity=waffle ... sounds like a nice tag :D
Anyway, I'll now shut my waffle.
|Top 25 cities in the world by the number of POI||2 months ago||
It would probably be more interesting to see POI density used in some way. Like POI per area unit, or POI per population.
Many cities have different boundaries that would yield different results. Like in the case of Brussels, there's the municipality Brussels (aka Brussels city), and the Brussels-Capital Region. But about the entire Brussels-Capital Region grew together into one big city.
Brussels city has only about 170,000 inhabitants, but with an area of just 33 km², that's about 5300 inh/km². Brussels Capital Region has 1,160,000 inhabitants, with an area of 161 km², which makes 7200 inh/km². So even though Brussels city is considered the city, it's clear that the entire region is in fact the city, and selecting one of the two will make a difference in the measurements.
When counting the POI, Brussels city has 2627 POI (http://overpass-turbo.eu/s/bC4) and Brussels-Capital Region has 11491 (http://overpass-turbo.eu/s/bC6). That's of course a serious difference. But Brussels city has 0.015 POI/inh, while Brussels-Capital has 0.009 POI/inh, and Brussels city has 80 POI/km², while Brussels-Capital has 71 POI/km².
So in both cases, I'd call Brussels city to be mapped better than the surrounding region, although in absolute number of POI, Brussels city has a lot less. I think it would be a lot more interesting to compare these POI densities rather than the absolute numbers.
|hilfe Fehler beim importieren von Wegen||2 months ago||
I'll try to answer in German below, but my German isn't really good enough for that. Hope you understand it.
The GPX feature of OSM is made to gather real GPS data in order to improve the map, it's not meant to publish data exported from some app (possibly based on copyrighted maps). So there are certain requirements for the GPX tracks. One of these requirements is that every point should have a timestamp. Having a timestamp makes it more likely that the track is real, instead of exported.
Die GPX Merkmal OSM ist um echte GPS-Daten zu sammeln und die Karte zu verbessern, ist es nicht gemeint um Daten zu veröffentlichen die von einem gewissen App exportiert sind (möglicherweise auf urheberrechtlich geschützte Karten basiert). So gibt es bestimmte Anforderungen an die GPX-Tracks. Eine dieser Anforderungen ist, dass jeder Punkt einen Zeitstempel sollte haben. Einem Zeitstempel macht es wahrscheinlicher dass die Strecke wirklich ist, statt exportiert.
|POI nodes with over 100 tags||2 months ago||
It's easy to convert a list of node ids into an overpass query to query the actual tags: http://overpass-turbo.eu/s/bwx (the actual json is under the data tab).
I did it with some search-and-replace operations, but you could also have a script that reads your geojson and just outputs an overpass query. As overpass can't count tags (yet), it's not possible to use overpass to get your original list of ids AFAICS.
|Postigs question - find out the unnecessary points that exist on the map||2 months ago||
This shouldn't be done inside the OSM database, but osm editors should make sure this doesn't happen (by showing a warning when there's such a node f.e.).
Also, wrt your example, it depends on how you measure angles. To take an extreme example, if you have a straight line from London to Beijing, the shortest distance is through Finland, and not through central Europe. So if you have a centre point somewhere in Ukraine, it might be a zero-angle point on a Mercator map, but it won't be a zero-angle point when using exact shortest-distance lines. This effect also always play up on shorter lines, so every point in the database will be a non-zero angle according to some projection and a certain precision.
Btw, many data consumers already use the Douglas-Peucker algorithm to remove any points up to a certain precision when processing it. Like OsmAnd compiles their obf files while applying Douglas-Peucker in order to shrink the files.
|What's your OpenStreetMap story?||6 months ago||
When I got my first android smartphone, it had a GPS, but mobile internet was slow and expensive. So I bumped into MapDroyd (http://wiki.openstreetmap.org/wiki/MapDroyd) which offered offline map rendering for free. Coming from paper maps, that certainly was enough for me ;)
However, when checking out the maps, I saw that my own street had missing parts, next to many other missing streets. Luckily, the app had clear credits, so I could figure out that the maps came from a Wikipedia-like project called OpenStreetMap, and I started tracing roads. At the start, that was done just by running a tracking app in the car, uploading the traces to OSM, and tracing them in Potlatch (adding details from memory).
When the streets I often took were mapped, I also started using the bike to map streets I don't need (like dead-end streets), and more dedicated apps like OSMTracker (that could take pictures).
So I started contributing for some reasons:
|Netherland housenumber evaluation available||7 months ago||
Oh sorry, I didn't notice the OSM date. It looks like the Flemish OSM data is from December 2014, then those percentages can be correct indeed.
|Netherland housenumber evaluation available||7 months ago||
I see you also do validation for Flanders, but that most of those have a very low percentage. Any idea how that comes?
F.e. for Staden (which is the most yellow one in West-Flanders), the percentage you give is 85%, while on my tool it's 95.7% (http://crab-import.osm.be/import.html?pcode=8840&loadOsm=true&collapsedSections=export#data)
But worse are the neighbouring municipalities, like in Langemark-Poelkapelle, you give around 20% (not sure why you split up between Langemark and Poelkapelle, it's one municipality), while my tool gives 99.4% (http://crab-import.osm.be/import.html?pcode=8920&loadOsm=true&collapsedSections=export#data)
Note that in Belgium, housenumbers are not unique inside a postal code, but streetnames are unique inside a postal code, and housenumber are unique inside a street. Postal codes map one-to-one with municipalities most of the time. Only big municipalities have more postal codes.
So we do need to compare streetnames, and take abbreviations into account. But you can check out all code and data here: https://github.com/aptum/aptum.github.io