Dear Frederik, I find myself having some difficulty to understand the way
you are addressing imports. There seem to be two camps now. And, while the
Dutch import tries to get as many local people as possible involved (7 at
the moment, and that's still just the number of beta testers), you refer to
that import as a bad one. That's impacting some of the beta testers in a
negative manner unfortunately.
OSM will soon celebrate it's 10th birthday, and you have experienced the
development of the project since it was an infant. Would you please share
what your view is on OSM in the foreseeable future (2020 or so) and by what
path OSM might get there?
Cheers, Johan
2014-02-06 Jo <winfi...@gmail.com>:
> I'm a long time contributor to OSM and the way I understood it the goal
> was to get more and more detailed information as we go along. So me and
> other contributors have been asking local government and PT companies to
> release their data.
>
> Now that the data is becoming available, it would be strange not to use it
> to improve OSM.
>
> In this light I agree that it's not useful to simply dump all that
> information into OSM, like it was done in the Netherlands and the US
> several years ago.
>
> It's important somebody actually integrates it in what we already have.
> The way I see good imports made possible is by providing the local
> contributors with pre-chewed layers of converted OSM-data and tell them
> where to find it.
>
> It's also necessary to tell them we're in no particular hurry to get all
> that data added.
>
> So when somebody is working in an area, they can load a few extra OSM and
> WMS layers in JOSM, or they can go to a web site and download all the house
> numbers for the street(s) they are interested and have time for at that
> moment.
>
> This is in contrast with the requierement to use a dedicated account for
> importing that data though. If the powers that be keep that impractical
> requierement, then it makes more sense to log on with that account and
> simply dump the whole lot in in one swift go.
>
> Instead of solitary users importing/dumping data, what we need is sources
> with data available for importing/integrating and a way to let people know
> what is available in the area they are working on.
>
> Just my $0.02
>
> Polyglot
>
>
> 2014-02-05 Frederik Ramm <frede...@remote.org>:
>
> Pieren,
>>
>> I'm replying to you here and to those who without further comment
>> "+1"ed your message. I know that your background is the French cadastre
>> import but I'm trying to remain generic.
>>
>> > The question is more to know if address data is something valuable for
>> > OSM or not.
>>
>> OSM is about community first, and about data second. (This is trivial
>> and not up for discussion - if we lose the data but still have people we
>> can re-create the data, but if we lose the people then we're done. If
>> anyone is of the opinion that data is more important than people, don't
>> read on - we live in different universes.)
>>
>> Whether or not importing a certain data set is a net gain for OSM must
>> be judged in the light of the question: Will this increase the number of
>> people who participate in OSM, or at least make life better for those
>> who already do?
>>
>> That's why in this discussion I asked about local communities working
>> with the imported data.
>>
>> If the answer to my question above is "no but the map will be more
>> useful", then that is not sufficient reason for an import - I can then
>> simply mix-in the external data into Nominatim or a tile serving database.
>>
>> > Of
>> > course, the community already answered to that question : it's much
>> > easier to do this merge and consistency check only once for all
>> > consumers in the same database.
>>
>> Very often, we don't see "the community" importing, but a very small
>> number of indiviudals, often without even talking to the community
>> before they dump their supposedly helpful data ("sure the map is better
>> with my building footprints than without?????!!!!") onto OSM and leave
>> us to sort things out.
>>
>> These people don't mean evil - they just don't know enough about OSM to
>> see the error in their ways.
>>
>> That's why in this discussion I asked whether this import had been
>> discussed in the community, or whether it was just one guy trying to be
>> helpful.
>>
>> > If someone find a mistake or something
>> > outdated, it is fixed once and for all consumers at the same time.
>>
>> Sadly, no. We have many, many imports in OSM that just rot along, and
>> where precisely nothing is fixed, for years. One quick look and you find
>> lots of places where anyone can see that something is wrong, but it is
>> *not* fixed. This is particularly bad in the USA where in some places,
>> three different layers of non-matching imports are piled atop each
>> other, with nobody giving a damn about the obvious problems - if you, as
>> a newcomer, were to look at that map, you'd probably say: "Uh, this
>> doesn't look like anybody in OSM is interested in a good map. Cleaning
>> this up is too much work for one person. I'll come back when it is fixed."
>>
>> We have imports where stacks of house numbers are at the same location,
>> making editing *more* *difficult* for people. We have imports where
>> what, in reality, is a nicely lined-up row of residential buildings, is
>> a jumble of rectangles at varying angles - often more work to get them
>> right than to trace over imagery in the first place. Imports like these
>> make OSM worse, not better.
>>
>> That's why we have to discuss each import individually and try to
>> ascertain that it will make OSM better, not worse.
>>
>> Imports can be valuable when they fall on fertile ground, when there's a
>> community using the imported data to improve the map. When there's
>> nobody to check whether the imported data is any good at all, and nobody
>> who cares - "this is government data, how wrong can it be, and anyway,
>> if it's wrong I'm sure someone will come along and fix it!!!" - then
>> imports are a liabilty.
>>
>> > The question about keeping the data up-to-date is a general challenge
>> > in OSM, not only for data imported.
>>
>> True but imports often drastically worsen the ratio of contributors to
>> data. If two mappers in a city cannot keep 1.000 objects current, that
>> is not a license to dump 100.000 more objects on them ("they couldn't
>> keep it up to date before either").
>>
>> > When a country or a
>> > municipality is publishing and opening its address database, it's also
>> > not falling from the sky. This data is also the result of many
>> > contributors, skilled workers, collecting and keeping the data
>> > up-to-date (at least, trying to).
>>
>> This is not universally true, and has to be assessed in every individual
>> case.
>>
>> > If addresses are released in open licences by public authorities, it
>> > would be foolish to not take this opportunity to considerably speed-up
>> > the task.
>>
>> I repeat - if there is no community in OSM that actually cares, then it
>> would be foolish to dump that data into OSM - it can easily be mixed in
>> if desired.
>>
>> If there are local mappers doing addresses, and asking for help by
>> importing some data to speed up their task, then that might be another
>> matter, because then there's hope that we have a chance at
>> cross-checking the data and fixing problems by people who live there.
>>
>> "By people who live there" is one of the key strenghts of OpenStreetMap,
>> and I don't want to see that squandered by people importing data in
>> areas they have never even been to!
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
>>
>> _______________________________________________
>> Imports mailing list
>> Imports@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>
>
> _______________________________________________
> Imports mailing list
> Imports@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>
_______________________________________________
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports
