[OSM-talk] Tools for a better tomorrow

john whelan jwhelan0112 at gmail.com
Tue Feb 22 02:05:22 GMT 2011


I think you have to accept that many "imports" come through JOSM, the
incident that initiated this thread wasn't an import problem as such just an
incorrect selection and hitting the delete key too quickly in JOSM.

Given the turn over of new people collaboration will always be a problem
especially as many people map from aerial or satellite images.  Not every
one is interested in spending time over a beer or coffee before going out
mapping.

There is a problem with some older data in regard to incorrect street
names.  I found more than a hundred in my local city.  Unfortunately they
are difficult to confirm unless you are on the ground and damage the
credibility of OSM.  Moving to OdBL may get rid of some of the older work
which maybe more prone to this sort of error.

There is a great danger that OSM organisation as it is today will become an
interesting piece of history.  In the computer world things move very
quickly and yesterday's darling is irrelevant today.  A map based on
importing the road network that includes correct street names and addresses
using OSM tools with added POIs based on street addresses if they find the
right imports would tend to be favored by many map users.

We need better tools for validating tags.  Give something the wrong tag and
it doesn't ever appear in a render.

Cheerio John


On 21 February 2011 19:49, Serge Wroclawski <emacsen at gmail.com> wrote:

> I think there's been a useful discussion in the other thread for ideas
> which might help the project move forward, and so I'm going to lay
> them out and hopefully we'll have a more focused discussion.
>
> Idea 1: Better collaboration, especially regarding changes people make.
>
> This is something that several people expressed as an issue. They want
> to be able to discuss changesets better, and be able to refer to
> changesets in changesets.
>
> I have some ideas on communication which I hope to announce in a few
> weeks. As for changes in changeset, I think that could be solved with
> a new changeset tag "refers_to" or "child_of", and the value would be
> the original changeset.
>
>
> Idea 2: An "Import" Layer
>
> The idea didn't come up this way, but one of the topics of discussion
> at a recent Wikipedia event I attended was the importance of Wikipedia
> Commons. Where Wikipedia is a secondary source, Wikipedia Commons
> allows users to upload primary sources for access.
>
> In the OSM context, the idea was for us to have an upload function
> like we do for GPX, but that would support import data, such as
> shapefile, KML, etc.
>
> This data could be used by users working on data.
>
> Idea 3: Better import testing
>
> If people are interested, I talked about this idea a while back, of a
> testing framework for imports and bots.
>
> This can include maps, but also (I think) should include seeing some
> sort of changeset of proposed changes, and allow users to comment on
> the process and output, before it hits the main database.
>
> Idea 4: Better comparison tools.
>
> A common concern by those wanting to do imports is we lack good
> comparison tools.
>
>
> Are there other things folks think we need or could be doing better?
>
> - Serge
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20110221/55b10293/attachment.html>


More information about the talk mailing list