Same thing here. With Firefox on Ubuntu 13.04 64 bits (dual core with 4Gb of RAM). JOSM is super smooth, potlatch works okayish, iD is dog slow keeping one CPU at 100% almost all the time :-(

@seav: My main advice is: “take it easy” :-)

Currently, all this has to be taken with a grain of salt. * Firstly, the rendering you’re seeing has been coded by Christian, on his own initiative, and mostly for demonstration purpose. It’s not the most clever rendering ever (yet), and doesn’t set in stone the meaning of any tag. * Secondly, like most of the tags in OSM, the semantic of the leisure=pitch tag is not fully specified. The wiki page gives a pretty good rough idea, but what matters most is how contributers use it to map the reality to the OSM database. I’m sure currently you can find in OSM both interpretations of what a “pitch” represents: either the whole group of courts (easier to map), or just one court (easier to render, and more precise).

In my opinion, every contributor has his own right to pick the interpretation he likes most, at least until there is a consensus which emerges. So I think for now the most important rules are: try to stay consistent with yourself (decide how you want to tag things and try to stick to it for some time), and respect the work done by other contributors by not changing their tagging just to fit your interpretation.

I’m absolutely not involved in the project, but indeed it seems it’s based on CartoCSS: https://github.com/cquest/osmfr-cartocss

You can contact Christian Quest for more information :-)

There is a 179 between 77 and 83. Isn’t this a typo? It looks like it should be 79 (it doesn’t look like the ordering is that bad).

Hi NE2, It seems Paul Johnson has really carefully put (and put again) the turn restriction there, and pretty unlikely that the people who made this cross road ever envisioned the movement you’ve described as being acceptable. I agree with you that local knowledge always has priority, but the opposite side seems to have a point.

So I’d highly recommend you to not go onto the “edit war” path. Especially, it is not advisable to mention “vendalism” in your commits messages for such behavior: it’s pretty obvious that Paul Johnson is not willfully damaging the map.

The best is that you continue discussing this case on the mailing list, where a discussion is already going on: http://lists.openstreetmap.org/pipermail/talk-us/2013-February/010341.html

It seems that, as Vlad described, the coastline has been updated, but because no data has been changed since the update, the tiles haven’t been refreshed.

I’ve just forced the refresh at zoom 17, and the coastline is now correct. So apparently it’s eventually going to appear fine, but will take time, unless you force a refresh at each zoom level.

On the wiki they state that they follow IHO S-57, which can be fully downloaded there: http://www.iho.int/iho_pubs/IHO_Download.htm In the appendices there is a list of all objects and attributes possible.

Isn’t it enough information? Maybe you could explain exactly the type of information you’re missing on osm.wiki/Talk:OpenSeaMap

Éric

I’d follow Vincent advice. The name of the building is the “Palazzo Pamphilji”, which will always be this even if the owner changes (and maybe also a tag tourism=attraction as EdLoach suggested). Then you add a POI inside the building with the embassy amenity. If the Brazilian embassy decides to move, it’ll be just a matter of moving the POI.

Sometimes the changes in the map are not detected by the renderer. You can force it by adding /dirty after the url of a tile. I’ve just done this, and I think it’s now fixed for each zoom level (you still need to refresh the page in your browser).

Just a tips in addition to Sander’s comments. In Potlatch you can connect two ways by doing the following: * click on the way you want to connect * drag the node at the end of the way on top of the other way * press “J” (like “join”) * you should now see that the connection node is bigger than other nodes of this road.

BTW, you usually don’t need to fill all the information on the street. If it’s the “standard” value, you don’t need to mention it. For instance, if it’s allowed to go in both direction on the street, it’s usual to not mention anything about “oneway”. “oneway=no” is fine, but not necessary. Same goes for motor_vehicles, access, foot, maxspeed…

Have fun editing :-)

Hello, I agree with almost all your analysis. However for “externaldatabase:id”, I’d be more prudent. In particular, there might be “databases” that can be complementary to OSM. We don’t want to store everything in OSM, and they don’t want to store everything related to location on earth. I have in mind the “wikipedia” tags, see osm.wiki/WIWOSM

Éric

@Gnonthgol Could you explain more the problem, I’m not sure I’m following. You mean that the imagery is correctly aligned for the coastline, but for everything in altitude it becomes shifted (due to the view from the plane in “diagonal”)?

For villages, which are in many cases situated at low altitude on relatively flat areas, shouldn’t this distortion be small? Isn’t having the streets and their intersections approximately situated better than nothing at all? Especially, with a couple of GPS traces, it should be possible to realign all the streets of a village?

Hello, Concerning the S/N roads. I believe “S/N” stands for “Sin Nombre” which is Spanish for “Without Name”. So it’s probably there to mean that in the import the name was unknown. I doubt it means it’s a service road (and if you look on the imagery, many road called “S/N” are pretty big roads).

Concerning the S/N roads in Peru. This doesn’t mean they are service roads. I’m pretty sure it stands for “Sin Nombre” which means “no name” in Spanish. Apparently in the import of Telcom IP, every street without known name got named “S/N”. It’s an horrible idea. Nevertheless they might still be big roads, and actually it’s unlikely any of them is a “service road”.

Hei, I’ve been working a bit on this (on and off since a year), as a couple of other guys. Actually the Telcom IP import covers the whole Peru. It has many bad sides (e.g., low quality of positioning, missing segments of roads, same road represented by many segments, roads without name named “S/N”, names all in upppercase), but it has one big advantage: it has the name of many streets.

So now what I usually do is: 1. map using the satellite imagery 2. name the street using the name of the close by segment from Telcom IP 3. delete the Telcom IP segment

Usually, I leave the name in uppercase, to mark it’s coming from Telcom IP. I guess later on, when everything is converted, it will be possible to fix it with a bot.

For Lima precisely, I can give you a couple more advises: * Some places look like already mapped, but the Telcom IP and the satellite imagery haven’t been merged (step 2 and 3). It looks ok from a low zoom, but if you zoom in (or use JOSM validator) you can detect that case. * The bing imagery has quite a big shift (~20m), so you want to align it first on existing roads/gps tracks.

Have fun & good luck! Éric

Welcome to OSM!
To support you I've mapped the Vila Boas district using Bing imagery :-)
By the way, be careful, I've noticed that in some areas many ways were doubled. I've tried to clean them up whenever I found one but there might be more.

Have fun!

That's great! I'm planning to visit Xi'an next year, so it'd be fantastic to have the map of the city with me on my phone when I arrive :-)

Which type of smartphone do you have? If you have an android-based phone, I can recommend you OsmAnd, which works great even when not connected to internet.

Have fun!

How do you tag them?

Indeed, one of the problems of rolling back the import is that it has now been from some time so it's been cleaned up a bit everywhere. But I guess it'd be possible to only remove what has not been modified.

Actually, the most ugly part are the duplicates. When it's not a duplicate, it's rather OK (it's like a GPS track with the additional information on the name of the street). I wonder if there is a tool to detect duplicates: look at the ways committed by "TELCOM IP", check whether the way is close from another way not from this import (within 5m or something), copy the name, and delete the imported way. Does this already exist?

Just to be clearer, I didn't copy the phone directory data into the map, I used principally the names which are in the cadastre (that the French authorities confirmed it was ok to use as a source for OSM). I'm using directory data only to get a second list, made independently, to follow the progress and ensure the quality. Actually the phone data I found is very low quality. It contains many spelling mistakes, missing words (like first name of people), and wrong street types (like "Street" instead of "Avenue"), so it would be impossible to use it directly.

When doing the comparison, whenever there is a discrepancy I try to validate the name by looking for it in the municipal newspaper, or asking some locals (eg: my parents).

I absolutely agree that doing it gives you a strong will for an actual tour around the place. I've already planned to go for a bike trip next time I visit my parents to see all these various places which I don't know enough to draw them yet!