[Imports] SASA bus stops import
tyr.asd at gmail.com
Fri Sep 27 11:24:59 UTC 2013
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:
Feel free to contact the data owner at open[at]sasabz[dot]it if you need
> 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
> 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
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. (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 ,?
Also, the German mailing list recently had a lengthy discussion 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 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?
More information about the Imports