The website code is at http://git.openstreetmap.org/ Feel free to implement something immediately! If it is a practical and sane solution, it might even get taken.

Until then, the levels of spam are just about still manually manageable. Annoying yes, but not catastrophic. A system to deal with it more efficiently will eventually come though.

The wiki template ValueDescription has a link to OsmDoc and Tagwatch. Isn't that "enough" as a "tool that includes both"?

Nice work on those links to the wiki btw. Perhaps that will help expose the tag descriptions more and encourage people to improve the description to make it less of a mess

Looks very nice. Particularly the chat is a neat feature!

If you don't mind, I will shamelessly mention my own version of it here though too LiveEditMapViewerJ osm.wiki/LiveMapViewer as it was heavily modeled after the original version of osmlive. It seems very similar to your current version, just without the Chat function and as a Java program instead of being a website.

Hallo und willkommen bei OSM.

Ich nehme mal an das du das Programm NaviComputer verwendest? Das Programm muste leider von den OSM Tileservern geblockt werden, das es zu viele Resourcen der server verwendet hat und somit angefangen hat andere Nutzer zu beeintraechtigen. Der Sinn hinter OSM ist zwar freie Karten zu produzieren und jeder kann sie (hauptsaechlich die Daten) verwenden fuer was auch immer er moechte, aber die Kapazitaet der Server, die rein aus Spendenaufkommen finanziert werden, ist leider begrenzt. Desshalb musste fuer diese eine Nutzungsbedingung eingefuehrt werden, gegen die NaviComputer verstossen hat. Sobald der Autor des Programmes also ein paar Massnahmen in das Programm einbaut um die Server nicht mehr zu ueberfordern, wird es auch wieder entsperrt.

Es steht aber jedem frei, aus den Rohdaten seine eigene Server zu betreiben. Dort gelten dann diese Limits logischerweise nicht mehr und es ist der bevorzugte Weg wenn man vor hat OSM in eine populaere Website oder Smartphone App einzubinden.

Although the US might have disproportionate number of problems, road connectivity for routing is definitely an issue in other places too, including Germany ( as e.g. shown by the OSM Inspector ). Once people start using osm more for (hobby) routing, things will improve, as more people notice the problems and fix them. But it will be a bit painful at the beginning. Never-the-less, I do think it is one of the important use cases for OSM data.

In the future even more emphasis will thus have to be put on quality assurance to fix these sorts of problems. But our tools for that, such as keepright, are slowly improving, they just need to become more widely known and used.

Indeed, it will be hard to find an area that is sufficiently unmapped. But I think there is more than enough that still needs doing. So I suggest to change the format a bit. Rather than map some specific area around the pub, I would suggest we'd each map some specific aspect on our way to the pub.

For example check and close all the OpenStreetBugs on your way, or add traffic restrictions like maxspeed, turnrestrictions, maxweight, ... on your way. Another one could be to take the bus to the pub and map the corresponding bus route. And if we have really run out of things, there are always housenumbers. Again, if we do it housenumbers along the (major A roads) way, rather than in some area, it might be easier to motivate people.

I am not entirely sure what you are doing, but I don't think you can upload GPX waypoints to OSM, only GPX tracks. What you will have to do is load your GPX with the waypoints into JOSM and then create OSM nodes where the waypoints are, with appropriate surveillance taggs ( osm.wiki/Proposed_features/Key:Surveillance ) You can then upload those to OSM.

Ich glaub das unterstreicht recht eindrucksvoll wieso viele urspruenglich dagene waren so etwas an ein Unternehmen (nicht opensource) auszulagern. Man verliert die Kontrolle darueber und ist darauf angewiesen das die es sich nicht ploetzlich anders ueberlegen.

Soweit ich weis verwendet Skobbler den router von CloudMade und der wurde vor Kurzem auf eine Updatefrequenz von einmal taeglich umgestellt. Also nach ca. 24 Stunden sollten korrigierte Fehler dann auch in Skobbler auftauchen. Aber da kann ich mich auch irren.

In der ersten Incarnation des Rueckkanals verwenden sie auch glaube ich noch nicht OpenStreetBugs direkt, sondern zunaechst einmal ihr eigenes System / Webseite. Laut Blogeintrag, wurde das gemacht um erst einmal zu schauen wie nuetzlich die Rueckmeldungen fuer OSM sind, befor womoeglich OSB mit wenig hilfreichen Bugs geflutet wird. Das macht denke ich durchaus Sinn, das erst einmal beta zu testen und dann hoffentlich wenn es gut funktioniert, richtig zu integrieren.

Insgesammt duerft es ein guter Haertetest fuer die routingfaehigkeit der OSM Karte sein :-) Und bringt hoffentlich auch ein paar neue mapper.

On the point of adding more tile layers. I had sent an "inquiry" to talk-de the other day to see if they know of any tile layers that could be added to the main page, given a few basic requirements (the owner wants it, it is worldwide and it can handle the expected load). So far I have only heard back with one potential suggestion, the hike and bike map. http://hikebikemap.de/ It is currently hosted on the wikimedia toolserver, so once the rearrangement of the server has completed and it is running stable, that would be a nice candidate for inclusion. But unfortunately there really don't seem to be all that many options. Perhaps we will see more in the future.

Hopefully a disaster doesn't cover that large an area, so that the number of users contributing to the area beforehand isn't as large as making asking those people to relicense in the case of disaster impossible. I don't know if it is feasible, but I think that is one of the questions that should be asked in a proper review of what went right and what went wrong once things have calmed down again and in discussion of how to improve things for the sad certainty of the next crisis.

I don't think PD is necessarily at all about Google vs OSM, but rather can downstream users use either. Dupplicating efforst is annoying and wastefull, but not catastrophic, given the number of uneffected users willing to help is quite large and the limited information from "out of the field" can be shared by both. Not being able to use either by downstream potentially is.

Nearly all of the uses cases listed on the wiki page for use of OSM has been in mashing together variouse data sources (e.g. imagery, road vector data, elevation data, damage assessment data, ...) to create combined maps for distribution. Which if each dataset sticks a slightly different varient of "free" in their license means they are incompatible and noone can use anything.

Of cause, that is a general argument against viral licenses, but whereas normally I would say the advantages of viral outway the disadvantages, in the case of saving lives I think it doesn't.

When heise.de posted a blog entry about OSM help in haiti, several comments were along the line of "Oh, they are only interested in using the catastrophy for their own publicity and push the cause of OSM". Now heise is known for their Trolls and at first I thought those comments were absurde and that people only want to help in a way that they easily can. And I am still convinced that is true for the vast majority of people who have put in a lot of effort into the OSM haiti page to make it a great map. But I do get the impression there is a kernel of truth to those "alligations" and some people are emphazising the "battle" between OSM and MapMaker more than I think is reasonable.

Yes, I generally don't want to just give my data to Google without getting anything back and so yes I am a strong supporter of a share-alike license normally. But the reason I want a share-alike license is because I don't want to work for free and want to get paid for my work. Not with money but normally with more data. However here in Haiti, my payment would be that this work might save lives or at least help make it less devestating for some. This is more than Google can ever give back! So please, can we tone down this whole "battle" between OSM and MapMaker and just concentrate on makeing the best map that can help people as much as possible. Let downstream users who actually know what they need in the field decide which map better suits their needs!

And also we shouldn't forget that a not in-substantial part that made it possible for OSM to have such a good map was Google jumping over their shadow and explicitly giving OSM permission to derive maps in Haiti from their aerial imagery! It would be ironic if the dataset with the most legal hassels would end up being OSM!

So I would support releasing the limited haiti dataset PD for the moment to let all the aid agencies mashup OSM data with what ever other dataset they have and need.

This leaves the technical question of how to do it? I think it will be hard to come up with a good solution quickly, so it is probably to late for haiti, but we should think of structures of how to loosen licenses for a limited amount of data relavant to massive humanitarian crisis. I kind of like the idea recently brought up on the mailing lists of tagging each changeset with either PD or CC-BY-SA/ODbL. In the case of crisis, we could then ask (or potentially mandate?) everyone editing there to only edit in PD mode and thus create a small bubble of PD data for everyone to use as is necessary. This leaves the question of how to determine derivative works and how the viral part spreads. This is a hard question, no doubt, but with the move from CC-BY-SA to ODbL, we will need to develop these tools anyway!

I am only guessing but potentially Mapsomatic is not giving you the possibility to create a map of Barrie, ON as it doesn't have a boundary relation. Whereas Nominatim goes away and tries to guess a somewhat arbitrary city boundary, Maposmatic might just say "sorry, I can't do it without as it would be too inaccurate".

So incase you know the city boundaries, it would be great to add it. ( osm.wiki/Relation:boundary )

Zoom levels 11-18 on mapnik are ment to be updated that often, but it might be that client side caching interferes a bit with that.

The way it works is that the mapnik rendering database is updated with the minutely-replicate diffs. Then the high zoom tiles that were affected by the diffs get "expired", which means that the next time someone views one of the expired tiles, it gets rerendered.

Altogether, the delay introduced from someone uploading changes till it being visible on the map should be (and normally is) about 1 - 5 minutes.

There are a couple of reasons why this might not be the case though.

For one, it might be that the server is overloaded so can't render all the expired tiles in time. This is rarely the case though and isn't at the moment, as the server is sufficiently powerful to handle all the render requests.

Secondly, some changes don't correctly expire tiles. The calculation of which tiles to expire might not take into account all the various complex relations, but again this should usually not be the case.

Another case is that the individual tile you are looking at takes longer than 3 seconds to render, in which case an old tile is serverd, to not drive up perceived latency

And lastly it could be that you have viewed the area before the changes, your browser / proxy then caches the tiles for a couple of hours and you don't see that the server has rerendered the tiles already.

Apart from the incorrect expiry, all of the above should normally be solved using a shift (forced) reload.

What sort of latecies do you see? Is it hours or days that changes don't appear? Anything more than a couple of minutes with the occasional hour long delay is a bug / problem somewhere.

But as I said, that only applies to the main "mapnik" OSM map and other maps may be very differently with some potentially only updating once a week or less.

Which map are you referring to? The Main OSM (Mapnik) map, should be updated in about 2-5 minutes after new data comes in. Is this not working correctly? The t@h map is a little slower I believe with usually on the order of about 2 hours, but I am not too sure if that is still the case. I don't know how often other maps using OSM data update though

To support what the other comments have already said:

"We are providing waze free of charge to our users but we need to generate revenues and our business case is based on selling the data accumulated, derived and analyzed which has real value. As such whereas the users and drivers who contribute get the service for free, business and commercial usage will be priced to maintain and keep the waze service alive." ( http://www.waze.com/forum/viewtopic.php?p=3142#p3160 )

I think commercial use is very important for OSM and it is generally encouraged, possible and beneficial for OSM. I think the example of Waze though is more or less exactly the form of commercial use we wouldn't wont. As their intent would be to use OSM as a starting point, enhance it with their own community and then not give anything back to others or at most sell it expensively. This would go against the main principals of OSM which is to provide free map data.

If they agree to share-a-like, there is nothing in the license though that would prevent them from commercialising OSM data, which several other companies have shown is possible.

While were at google maps and TeleAtlas bashing, I might as well throw in my example too. This example is not a small little housing estate, but a redevelopment of a major road intersection right in the heart of London just to the east of the city. I think the redevelopment was finished in April and was updated in OSM the next day. Google Maps and Yahoo are still showing the old road layout. I wonder how long it will take them

Google:
http://maps.google.com/?ie=UTF8&ll=51.514285,-0.069995&spn=0.006517,0.01929&z=16

Yahoo:
http://maps.yahoo.com/#mvt=m&lat=51.515244&lon=-0.071947&zoom=17

OSM:
osm.org/go/euu6DfOj

1) As far as I know, the reason for dropping the last-modified header and replacing it with an etag derived from the md5 of the actual tile, is that the last-modified will change more often than the actual content of the tile. As the tile expiry and (meta) tile rendering over estimates the number of tiles that need to be rerender after a change in the data, many tiles get rerendered to the same content. If the cache expiry were based on the modified time instead, it would reduce the caching efficiency.

2) The dev mailing list is probably the best place to discuss this.

Yes, Nokia Java Runtime for S60 is a Java ME runtime, whereas JOSM needs Java SE. If you want to use OSM on your mobile, have a look at osm.wiki/Software/Mobilephones which has a good list of available software.

If you want to edit OpenStreetMap from your phone while out and about, have a look at GpsMid, it has at least some very primitive editing features, and allows you to change, add and delete tags on existing ways as well as add new POIs directly from your phone. Hopefully in the future it will support some more simple editing features such as the ability to change existing POIs.

Having a full fledged editor on the phone is probably rather difficult due to the tiny screen and limited input device capabilities.

Do you have any kind of phone? It is often not necessary to have a smartphone to do this, as many simpler phones are capable of doing that too. If it runs mobile java there is a good chance there will be an app that can take photos and record voice and if you have a builtin gps or a bluetooth gps receiver can geotag them for you. If your worry though is battery life, then that is indeed a different matter as typically it is difficult to get more than a days worth recording out of a phone, though you could probably recharge in your car.

Getting back to your original question, I think if you can do offline mapping with JOSM over an extended period of time depends quite a bit on where you are going. If you go to an area that doesn't have much OSM activity, chances are probably fairly high that you won't get any conflicts and can just upload it at the end. Also since API 0.6, you should no longer be able to "destroy" changes that were done in the meantime, as with the versioning of the data, JOSM would detect when there are conflicts and hopefully provide you with the option to resolve them. How well that works I can't say though and personally I would rather recomend to just take photo notes. At least for me that has in the past worked fairly well.