[Imports] SASA bus stops import

[Martin Raifer]

Hi!

Serge Wroclawski <emacsen at gmail.com> wrote:

> Fair enough, though that agreement isn't documented- there's just that
> one sentence saying it exists. With that, I'd say we need more proof,
> such as an email or whatever else you have that can serve as a
> document of record.

Well, the thing was negotiated in person and via email in the course of a  
few months. I've added the exact wording of the final confirmation email  
to the wiki page:

   https://wiki.openstreetmap.org/wiki/AltoAdige_-_Südtirol/SASA_Bus_Stops_Import#cite_note-1

Feel free to contact the data owner at open[at]sasabz[dot]it if you need  
more proof.

> But assuming the agreement is in place (because I trust anyone who
> makes their own pastrami)...
>
> I'd remove the source tag from objects. It doesn't help.

I added this tag because I've seen it on several other imported data out  
in the wild. But I guess you are right, the source tag on an object  
doesn't really help much and the "source" can also be seen from the  
changeset history.

> I would keep, if possible, some kind of ref tag identifier- for the
> reason I'm about to outline...
>
> But my biggest concern is this:
>
> "This is a manual one-time-import. JOSM will be used for checking,
> validation, conflation and upload of the data. "
>
> Manual, one time imports aren't generally very good. They're subject
> to bitrot of the highest order. And when you're talking about a
> feature which changes as frequently as bus stops, with bus route data,
> then the data is quickly going to become fairly large, complex, and
> unmaintainable, without some kind of updating plan.
>
> So, how will you update this work in a year? Two years? Five years?

If I understand you correctly you are only concerned about the lack of an  
updating plan and suggest that a "ref" identifier could help for that. Is  
there any documentation about good practise of such update plans? I cannot  
find anything on the import guidelines and all other import plans I have  
looked at also don't have any organized updating. Am I missing something  
fundamental here?

The original open.sasabz.it data contains some kind of "autoinc" id field  
that is also used on at least one of the company's "public" APIs[1]. (But  
as this API also requires the knowledge of the line-ids which is closed  
data it's practically useless for OSM data consumers. Also, it is not sure  
how stable these APIs and IDs are.)

I didn't plan to import any data that cannot be confirmed on the ground.  
Isn't that the reason why we are discarding IDs from past imports [2],[3]?  
Also, the German mailing list recently had a lengthy discussion[4] about  
importing an id-like tag where AFAIR the consensus was that only those IDs  
are "acceptable" that are openly documented and which provide a real  
benefit for data-consumers.

Currently, I was thinking about doing data maintenance as part of my  
regular mapping routine. SASA provides a Feed[5] with updates about  
temporary as well as permanent changes in their line network. If something  
"small" changes, I or other mappers that are subscribed to this feed can  
immediately fix it. Note that this isn't a nation-wide import; it's just  
two cities and a few towns in between (maybe ~200.000 people in the  
covered urban area).
If the SASA however decides to completely bowl down its network and come  
up with something new, we would have to redo the import with fresh data  
(but wouldn't that be the case regardless of this import or not?).

You say that “manual, one time imports aren't generally very good”. But  
what would be a proper approach to incorporating such data into OSM  
instead? I guess, an automatic, unsupervised import isn't the way to go  
either. So what would a proper import look like?

Best wishes,
Martin

[1] http://open.sasabz.it/doku.php?id=de:fahrplan
[2] http://gis.19327.n5.nabble.com/Discardable-TIGER-tags-td5718873.html
[3]  
https://lists.openstreetmap.org/pipermail/imports/2013-September/002133.html
[4] https://lists.openstreetmap.org/pipermail/talk-de/2013-July/103225.html
[5] http://www.sasabz.it/de/rss/