Probably better to edit http://wiki.openstreetmap.org/wiki/Spam

Gah - stop reminding me ! I know I need to get my act together and work on myself :p

Could have been meant in a lighthearted way, just forgot the “:)” at the end. But the place still needs to be mapped.

I remember reaching that milestone in my hometown too, years ago. Quite a giddy feeling :) The next steps (housenumbers and buildings, in my case) can take a looooong time (I’m still working on it here). And POIs are never finished.

Can’t read the message you posted, it is only readable by you.

It’s common enough for people to look at OSM and be surprised that part of their private property is mapped, and think that it shouldn’t be. Each time I encountered this, a quick explanation was enough to convince the property owner, and often even gain some local knowledge to improve the map.

As long as you’re only using public data (satellite imagery, non-trespassing survey…), are tagging things properly (don’t forget to add access tags when necessary, especially to prevent routers from suggesting a driveway as a shortcut between two road, but most driveways don’t need that), and are not including private information (such as “John Woo lives there” or similar), it’s normal to have it in OSM.

Start by explaining this to Dreganius. Whether he is or knows the owner isn’t actually important for the purpose of deciding what goes into OSM or not, what matters is the previous paragraph. Everybody benefits from a complete map; it would be pretty stupid for all the neighbouring houses/driveways to be mapped except this one.

After that, re-add the driveway, tagging it as access=private/destination if necessary. Local knowledge is needed before readding the name tag. If it is the name of the house, then putting it in addr:housename is probably the right thing to do. If it is the name of the people living there, then I agree that it is out of scope for OSM.

Currently all those track repositories are data silos, even in the rare case when the license allows extraction. It’d be great to have a sevice which would be good enough to be used by any willing party (say all osm-based satnav apps) in just a few lines of code.

Top of the head requirements:

• Anonymising (cut first and last part of trip, don’t export lone tracks…)
• Dead-simple upload API (REST, no account…)
• Permissive license (PD ? Ability to wipe own data ?)
• Pre-filters for HDOP, timestamps…
• Post-filters for speed, date, hdop…
• Auto-classify transport mode.
• Export/render point clouds, flow direction, speed histogram…
• Cheaply scalable

Ouch, that’s actually a sizable amount of work. But it’d be worth it if it improves uppon the very fragmented sources that we currently have.

Shouldn’t you add at least a name to http://www.openstreetmap.org/relation/2469776 so that OSM users can search for that particular golf course ?

You might be interested in https://help.openstreetmap.org/questions/48466/how-to-configure-offline-imagery-for-josm

It’d be great for somebody to help maintain this plugin.

Some background: http://wiki.openstreetmap.org/wiki/SVN Getting the source (no need for an account): svn co http://svn.openstreetmap.org/applications/editors/josm/plugins/terracer Another attempt at a terracer plugin (maybe not the only one): https://github.com/derickr/josm-plugin-uberterrace/commits/master

No need for permission to start hacking the code, only to upload to one of the osm-controled repos. Or if you don’t like svn, you could do like derickr and put your version on github or similar. Then work with derickr and pull patches from each other, and don’t forget to get your plugin listed in josm once it’s in demonstrably better shape than the original one.

BTW I’m not (much of) an OSM dev, I got all this info in a couple of minutes just by searching the wiki and the net, it was yours for the taking as soon as you started getting annoyed that fixing the terracer plugin wasn’t happening fast enough.

My experience of JOSM bug reporting isn’t that bad, reporting is certainly worth the time.

Concerning the “use latest snapshot” requirement, it is pretty standard as many projects use this to ward off duplicates and false positives. And in your case it should be pretty easy to grab that josm-latest and report using an up to date stacktrace ?

The problem of unmaintained plugins is frustrating, but it’s hard to blame the JOSM devs for code that they didn’t write (and apparently don’t use) and sits outside their repository. Terracer is really usefull and I’d like to see it in core… But that’s a feature request, not a bug report. I’m not sure what can be done to reduce the problem of onmaintained plugins.

Seeing no progress being done on a bug that affects you is of course frustrating. But venting that frustration by re-posting near-identical bug reports (1 2 3 4) is counter-productive. It wastes developer’s limited time and hurts motivation. It’s not surprising that it feels like spam to them.

If you’ve got new information, you should add it to the existing report instead of creating a new one, that’s a basic principle of bugtracking. If many months have passed with no reply it’s acceptable to add a polite “any news ?” comment on a report, but unless you’re a paying customer you should be prepared for a “sorry, no time, patches welcome” reply. Sometimes you get no reply, and that has the same implicit meaning.

An import and an editor are completely different things, you can’t applie the guidelines of one for the other. Sounds like you’re just looking for a justification to effectively ban maps.me contribbutors. A simplistic “solution” to a complex problem, hiding it instead of fixing it.

I agree that there are things that do make map.me contributions often sub-par (compared to the average newbie on other editors) : using old / incomplete data, and not interfacing with the osm community as much.

But these differences are not bugs, they are usecases. They need to be handled, not abandoned. Opening up editing to people who can only use offline data, or non-geeks who’d never read a full wiki page is an important thing to do for the OSM project, and I applaud maps.me for working on it.

Some issues are being worked on (more frequent data updates, multilingual names…) Some issues are trickyer (Improving the changeset discussion reply rate, foolproofing presets…). Some things are sorely needed but outside the scope of maps.me (better tools to detect and help newbies).

Don’t condemn maps.me, help them. They’re just the messenger of things to come, of practices that OSM needs to become ubiquitous. Other apps, like navme, arguably waste more OSM contibutor time than maps.me even though they only post notes.

As for the maps.me team: great work so far, but a lot more is needed :) And fix bug 3623 ASAP, it’ll reduce the community flak.

I stay away from w3w, mostly because it isn’t free but also because it has only one precision, and is rooted in one language (they make other languages available, but converting is no fun).

IMHO a Lat/Long encoding shoud:

• be completely free
• be short enough to remember
• be language neutral
• have a variable precision
• have an error correction

I don’t think that having nearby locations share similar codes is that important, since you’re going to ask your device to show you the map anyway, and the error correction protects you. But most elligible systems have that property anyway.

The problem is that we have so many competing similar solutions, and that none have a clear popularity advantage. Some are backed by a company, which helps adoption (sadly w3w seems so far to be winning the marketing game) and some are pure free systems.

Another annoyance is that because they are all similar, it’s hard to tell one code from another (say an openpostcode one vs an openlocationcode one).

These days I’m kind of tempted to follow openlocationcode. It doesn’t define an error correction code, but its Google backing makes it more likely than others to reach critical mass. Country-specific codes like openpostcode are still atractive, though.

On of my favorite confusing term is “chalet”. It’s originaly a french word where it indicates a small(ish) wooden house in the mountains. But in English (and OSM) the meaning changed to indicate self-catering individual tourist accomodations.

This kind of problem is inescapable with human languages. All we can do is make sure the wiki explains these well, and that editor’s tagging presets are well translated. Ideally they should even be locallised (which is a step above translated), but this requires a lot of work.

Nice writeup. Note that maps updates and app updates are separate things, and that the maps.me devs are working towards making map updates much more frequent.

I love that maps.me is becoming an editor, it has a lot of potential. But it’s not aiming to ever be a full editor. If you need to do anything more that simple POI editing, have a look at vespucci instead.

Try asking your question on osm’s help site or is arcgis’s own user forum. I’m not sure I understand your question properly, but it seems more related to arcgis than osm.

Some of the issues, in order of importance:

• The outer way is tagged as waterway=riverbank (equivalent to natural=water water=river). This means that even if the multipolygon is correct and should make the islands visible, there is another single-way polygon around it which doesn’t care about the islands.
• The way you highlighted in your screenshot is not a member of the multipolygon. Add it with role “inner”, like the other islands.
• The polygon is tagged water=river but not natural=water. According to the wiki, water=* is a refinement of natural=water, and should not exist without the later. water=* might work on its own for some consumers (like the default osm rendering), but not all.
• All islands have apparently been traced from Landsat imagery, but you might want to use Bing or Mapbox, which have a higher resolution.

Happy fixing :)

Great work, good to see OSM’s oft-cited strenghs actually applied in practice. And it’ll hopefully increase the number of OSM users and contributors.

You say you got the boundaries from “various sources” but point at an opverpass query, so isn’t the source just OSM (with some post-treatment to make sure the inda-approved ones are chosen) ?

+1 this calls for improving routing software, not routing/permission data.

iD still can’t set anything else than a comment on changesets, so its numerous users can only tag source=* on individual objects (and also tend to overload the changeset comment with stuff that’d be better placed elsewhere, like hashtags).

IMHO taging the objects is useful when things are not straightforward (typically when multiple source:= tags are needed), but that’s an optional addition to tagging the changeset.

When you want to know the source of some data, the source= tags on an object are never as good as looking up the object’s history anyway. Object’s source=* tags are rarely updated. The changesets date, user, comment, source, and imagery tags are invaluable and easy to fetch.

Yup if the lake is big enough, landsat can be used. Not sure how many of those are left to trace ? And yes whatever you autotrace from, a manual check/tweak afterwards is important.