There’s going to be plenty more like this to take care of. It’s a pain, but a necessary one and we’ll be glad to be on the other side.

Once the bot has finished processing the area, go ahead and “remap” the broken bits as well as you can.

Remember that nearly all trekking devices have an “average waypoint” feature that will wait for a bit until it’s sure that the measured position is correct. And you can take extra measurements a few hours or days appart.

It may not be as good as those overly-expensive professional GPS, but it’s more than enough for mapping in most cases. You won’t trace a road with it, but it’s perfect for alingning imagery.

Si tu as lu le wiki et que tu sèche encore, il va falloir poser des questions plus précises sur ce qui te pose problème. Je te conseille d’aller sur le channel #osm-fr d’IRC, tu y trouvera des utilisateurs de cadastre qui sauront te guider.

“Very quiet” ? There’s 7000-8000 distinct contributors uploading one or more changesets every week. A good chunk of those are in the UK. It’s more likely that there are too many edits for yours to be commented on, rather than nobody being interested in your area :)

Bloging is only one way to get chatty on OSM. There are a few others, mainly IRC and mailing lists.

Good work linking the Monmouth Wikipedia project with OSM. Keep it up :)

I don’t really see any problem here. Everybody has to pay some bills, and if a large proportion of OSMF member have their own company, it’s probably because the kind of people who volunteer for a foundation is also the kind of people who would start their company.

Does it cause a conflict of interest ? Yes and no : if their business is OSM-based, they’ll want OSM to trive, just like the rest of the community. Commercial use of OSM is a perfectly valid use-case (if not, we’d have a different licence). It’s even an important use-case, because commercial use brings sponsoring and visibility.

A conflic of interest would arrise if somebody pushed for something that’s detrimental to the rest of the community. If you spot one, then certainly go ahead and denounce it. But I dont see any here.

DB bloat is always something to keep in mind (throwing more hardware at it only works to a point), and Frederik Ramm’s comments about buildings is not about deleting it, but about thinking of ways to deal with it (also, it is not an example of DB bloat).

I have no idea what you are trying to say about the license bot (that it is progressing slowly ? we know that) or about http://openstreetmapdata.com/ (he shouldn’t have a donate button ?).

Nice, it’s going to be usefull.

One false-positive I’m seeing all around though: in a residential area or commercial area, it is common (and correct) to have the street named the same as the area. There’s also the case of “name=Foobar House” which is arguably both the name of the building and the area around it.

Not sure how to remove those false-positive without creating false-negatives, though.

C’est le genre d’info qui n’est pas affiché sur une carte, mais qui est utilisé par les moteurs de routage.

En plus des tags max*, je suggèrerais aussi l’utilisation de lanes, car un “lanes=1” est une bonne indication que cette route est déconseillée pour un camion.

Siehe auch wheelmap, eine Karte die speziel für Behinderte geeignet ist (Toiletten, Restauranten, etc).

Fixing OSM data is needed and important (in fact it’s the whole point of being an OSM contributor), but it sounds like your over-enthusiasm causes two problems :

1. You’re going too fast when deciding wether something is an error, and make generalizations when you should proceed on a case by case basis. For example, is_in is valid and good in many places, and the S/N in south america deserves surveying/imagery (as opposed to anthing automatic) to be fixed properly.

2. You try to bypass the community advice in order to go faster. It’s true that discussion slows things down, but it’s necessary to avoid big mistakes.

Dont take this as a “me VS the others” chalenge. We’re all working together to improve the map (and we need all the manpower we can get). The temporary block you got is just a warning that you’re doing it wrong, and risk making as much of a mess as you intended to fix. Learn from that warning :)

Sorry for answer in English, my german is lacking :

Why not simply use your browser’s “view -> zoom” feature (with “zoom text only = false”) ? I use this regularly (even on the same website/screen, depending on tiredness and ambiant light), there’s no way any given website’s pre-set size coult suit me every time anyway.

Bienvenu au club, amuse-toi bien.

The diffs are at http://planet.openstreetmap.org/redaction-period/ as explained on http://blog.osmfoundation.org/2012/04/04/api-read-write-returns/ . The full planet is still at the same place as usual.

It is working!!! Problem details, please?

* There's no way a license change could have got 100% approval. All things considered, I think the ODBL/CT did pretty well at being accepted.
* at this stage, decliners and undecided are pretty much equivalent for remapping purpose.
* If I'd feel punished by anyone, it would be by the non-agreers rather than by the OSMF. Remapping is a pain, but a necessary one.
* If remapping feels too boring, by all means do "normal" mapping instead. Mapping is still essentially a hoby for most people, so we'd much rather have you enjoy contributing in the forsteeable future than leave because you performed boring task out of "duty".

For that kind of calculation, load the exported data into postgres (many tutorials available on wiki for that) and run an sql query on it. For example, this one calculates total road length in the french city of Montpellier :

SELECT w.tags->'highway' as highway, count(*) as nb, sum(st_length(st_transform(st_intersection(w.linestring, poly),2154)))/1000 as km FROM (select ST_GeometryN(st_polygonize(w.linestring),1) as poly from relations r JOIN relation_members m ON (r.id=m.relation_id) JOIN ways w ON (w.id=m.member_id AND m.member_type='W') where r.tags ? 'ref:INSEE' AND r.tags->'ref:INSEE'='34172' GROUP BY r.id) AS v JOIN ways w ON (w.tags ? 'highway' AND ST_Intersects(poly, w.linestring)) group by w.tags->'highway' order by km desc;

It would obviously be simpler if you don't care about selecting just a part of your extract. Just don't ask *me* to detail the query to you, I only witnessed it in an IRC chat :p Look for postgis ans osmosis tutorials, and ask your question in help.osm.org instead of your diary.

I've never witnessed that. It sounds tempting but... what about the common case of a building containing multiple POIs ? I wouldn't like to have to deal with "smart" software in those cases.

Hum... Je ne passe pas beaucoup de temps sur les parties francophones d'OSM, mais instinctivement j'aurais traduit ca par "segment", qui n'est pas dans le doodle.

It's working hard but it doesn't seem overloaded just yet :

http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/index.html
osm.wiki/Servers

The wiki (osm.wiki/Lanes) only mentions creating multiple ways if there is a separation, so I'd go with lanes=4. There's also tags for unevenly-distributed lanes, bus/cycle/foot lanes, etc.

PS: try http://help.osm.org/ instead of the diary for such questions.

That'd be Bing's "global ortho" project, and yes, it rocks :) We have our hands full up here in Ireland/Europe "digesting" the new imagery into OSM data.

http://mars.jrc.ec.europa.eu/mars/content/download/2440/12571/file/Nov_2011_Bing_Maps.pdf
http://www.bing.com/community/site_blogs/b/maps/archive/2011/06/27/bing-maps-unveils-exclusive-high-res-imagery-with-global-ortho-project.aspx