If I understand correctly this is strictly a client-side endeavor, but in order to contribute it requires setting up a server with fairly hefty storage and performance, and also expertise with Tilekiln. Is there any way to make it easier to contribute to just the client side, allowing contributors to focus on the meat of the project?

Small edits are great! I often do the same thing.

If you’re using iOS you can get this information from Go Map!! under Settings - Nearby Mappers.

This is really valuable and an amazing effort.

Agreed, if nothing else please upload a GPS trace of your travels.

Thanks for relaying the details on the board meeting since I don’t follow them otherwise.

I’ve never worked for a mapping company but I do appreciate the contributions that companies like Mapbox, Microsoft and many others make to support OSM and improve our open map. I believe it’s possible to have a mutually beneficial relationship and I welcome their ideas, while also recognizing the need to be true to our open data vision.

Yes, this is spot-on. It’s confusing having to convert elevator/directory floor 3 to level 2. And many buildings are built on a grade and have entrances on multiple levels, so it makes the definition ambiguous whatever choice is made.

I always find the mapping of these densely packed urban areas to be both challenging and rewarding.

This looks great! Which imagery provider did you trace it from?

That’s awesome. I was on photo safari mapping trails around the game reserve.

Go Map!! silently creates an empty changeset during first-time password validation. It is invisible to the user and doesn’t imply that the user was attempting to edit and failed. (This “feature” will be fixed in the next release.)

The rendering issue was a font substitution bug that would occur for a street that contained a mix of English (i.e. Helvetica) text and a language rendered in a substituted font.

Relation editing is coming.

JOSM, Potlatch and other editors already have schemas they are using that could be automatically translated into something like the TagCentral schema, and that in turn could be semi-automatically imported into the wiki where it could be easily extended by users and indexed by TagInfo.

The editor schemas tend to be “top-down”: they say a node can be an amenity, amenity can be restaurant, restaurant contains cuisine. TagCentral is bottom-up: cuisine belongs to restaurant, restaurant belongs to amenity, etc. With the top-down approach you end up duplicating tag info that gets shared amongst many types of objects (“wifi=yes/no/free” for restaurants, cafes, pubs, etc.). But the bottom-up approach in some cases simply breaks: maxspeed belongs to highway, but not for highway=stop. TC doesn’t have a mechanism for these exceptions.

In any case the current wiki metadata is pretty close as it is. The main issue I see is that it uses a “combinations” field instead of TC’s “qualifies” so it does not sufficiently document the direction of relationships. It says that cuisine and restaurant are related but not restaurant is the primary tag and cuisine is an auxiliary tag.

I added the addresses in Hunts Point via JOSM in the evening after the training, then drove around the neighborhood the next day with my iPad verifying everything. The address data was perfect but several previously tagged street names needed fixing. Overall very easy and straightforward.

For v1 I had a bunch of testers and basically only one of them (thanks Skippern!) turned out to be an active mapper who used the app on a regular basis, so going forward (now that it is freely available) I’m going to add people as testers only after they have a history of using the app regularly for a couple weeks. This is especially necessary since the next version will focus on more sophisticated editing features and they need to get a reasonable workout. Make sense?

dcp: As Josh notes a port to Android is pretty much impossible.

Gregory: Please send me a screen shot and I’ll take a look

JoshD: I was involved in Sysinternals until just a couple years ago.

When mapping, especially places where I expect things to change a lot, I’m not so concerned with capturing an exact snapshot of the neighborhood but rather capturing the flavor of the area. As a traveler I don’t care so much about the exact restaurant but rather where to find a collection of restaurants from which to choose. And I assume that if a business fails it will be replaced by a similar business. A newer restaurant or a newer dry cleaner, or a newer gas station, but not something completely different. So especially in rural areas you can approach it this way.

Submitted to App Store last night, not sure how long it will take to go live.

The app is still under development and at present is only being beta tested by a few people, so it is premature to put it in the wiki. I hope that within a month or so it will be ready for public distribution via the App Store (free).

OpenStreetPad is a pure renderer, I haven’t seen any indication that it aims to support editing.