On 2014-06-17 00:07, Jo wrote : > Answers inline. > > > 2014-06-16 23:13 GMT+02:00 André Pirard <a.pirard.pa...@gmail.com > <mailto:a.pirard.pa...@gmail.com>>: > > On 2014-06-16 01:58, Jo wrote : >> Hi, >> >> The conversion is done. Municipality names are converted to lower >> case, restoring the accents. Route_ref is calculated. > > Many thanks Jo! > > > You're welcome > > > A few remarks. > > > Oh no! Should I drop the TEC project? > > As there were as usual no replies on this list to my remarks about > missing bus line numbers and accent-less uppercased place names, I > wrote to the TEC myself. They recognized my remarks as valid > points and they said that they will fix these problems, but no > sooner than September. I'll cc: you. > > I wonder if it wouldn't be wiser to "let's start !" in September > with that data rather than do it twice. > > > Why would we be doing it twice? What they will provide sometime after > September should have exactly the same contents as what my scripts are > calculating from the data they provide. > > Anyway, I don't see why it was needed to bother TEC with this. They > provide the data as is and it's our responsability to convert it to > something we can work with. I'm actually rather surprised you got a > positive answer from them. I don't understand you. Don't you find interesting if they used our lowercase names and we would just have to copy theirs in the future rather that have to compare their new uppercase names with the previous uppercase names to detect changes and make the corresponding changes in our lowercase names? More generally, don't you think that cooperation to synchronize with them is fruitful? If they know us, they might use our map and even, why not, update it themselves. Don't you like that hope? > > Whatever I try, I see accent-less uppercased place names in your file. > > > What did you try? 2 files found their way into the zip file. I hope > you were looking at the most recent one. I'm recreating them now. Like a ⅔ sized *.bz2 an *.osm.zip file is supposed to contain a single *.osm to be loaded as such in JOSM. Rather than explaining what I did I wrote in the frame below a skeleton of a procedure for the wiki. Failing other instructions, I acted logically with what you announced as "The OSM file ...". > In the mean time it's possible to determine whether a stop is new or > not. i.e. if a stop with that ref is already present in the > Openstreetmap data I'm downloading with Overpass. Basing your comparison on the data will get you into trouble. How will you do in the future when both OSM and TEC data will contain the same tags with possible different values because either TEC corrected an error or OSM corrected an error that remains in TEC? How will you know that the data has been updated? It's easy by using the source tags which are made for that and that I recommend below.
Now if you firmly intend not to use the source tag, PLEASE say it because I'm in the process of proposing a wiki update to make this easier with ISO dates and well explained and I would save me the hassle. > I thought that you had found the line numbers, but I don't see them. > > > They are in the route_ref key. Where did you expect to find them? In the route_ref key that I did not see. Plus, since beginning of May, I am asking if anyone saw line numbers. Especially with the SPW viewer that does not work. The data is supposed to come in shape and corollary files in a zip to be loaded right into JOSM. I did that. No line numbers I could see. I suppose TEC consider that the data must be simple to use (simply by loading the shapefiles) and not by difficult trickery. I wrote that I found this: > I made the following TEC => OSM tag conversion. > POT_NOM_HA => name > POT_ID => ref > POT_ZONE_T => zone There are two files containing TEC data. TEC_yyyy_mm.osm.bz2 containing the converted latest TEC data. TEC_todo.osm.bz2 containing the data remaining to be moved to OSM. Start JOSM and File>Download from OSM the area containing the data you want to update. Be careful, especially when loading new OSM data, to always have the correct layer selected. File>New Layer (getting selected) File>Open Location TEC_todo.osm.bz2 (loading TEC data to it) Select TEC layer and choose and select a TEC stop to update, usually a pair of. If it does not exist in OSM, Edit>Merge selection to OSM layer. If it exists: Check if source=survey yyyy-mm equals TEC yyyy-mm yes: you can Copy all Keys/Values from TEC and Edit>Paste tags them to OSM no: check for a Note explaining that a TEC value was incorrect and Copy&Paste only the rest Be sure that survey yyyy-mm and TEC yyyy-mm are updated to the new values: this is what is going to tell to remove the bus stop from TEC_todo.osm.bz2 Move the bus stop to the correct location, using Bing or other map layer. Periodically update the OSM data, using "TEC buses update" and checking that it updates what you've done. Loop for other stops. > > My file was displaying the lines (without number). Yours not. > Here is an additional layer to display them. > > > I never saw your file before I started. I wrote 6 messages about it and TEC without replies and you didn't ask. > > > https://dl.dropboxusercontent.com/s/ty49nmfdb2vfz4m/TEC_2014_04-Lignes.2.osm.bz2 > >> All that's missing at the moment is comparison with existing data >> already present in OSM. I'm already doing that for the stops of >> De Lijn, so the process exists. It merely needs to be adapted a >> bit in the scripts I created. >> >> I'm not adding source on the objects anymore. Instead I add >> source tags on the changeset as a whole. > On one hand, using a source= tag is highly recommended in the bus > stops and lines, if not required. > > > It's certainly not required. The tendency is towards adding source on > changesets nowadays. Look at buildings in France to see what adding > source on objects does. Our wiki states that source is mandatory. I don't believe in changeset tags being able to otherwise than fuzzily do what the source= with survey can do reliably. Plenty of reasons, including that they are not visible in JOSM, that it's a hassle for the user to tag each and every update and to make separate updates for any tag variation but that element tags are automatic without user action, that errors are not correctable, that JOSM documentation <https://josm.openstreetmap.de/wiki/Help/Concepts/Changeset> barely mentions only the comment tag, that OSM documentation <http://wiki.openstreetmap.org/wiki/Key:source> has absolutely no howto documentation, etc etc. The French are mad. I mentioned on Tagging@osm that they tag the same kilometer source on every node of a way as that on the way itself and that mailing list did not seem to consider it's a problem. Huffman is overworked ;-) > > > On the other, you must of course be able to tell data that was > added by copying the elements of your file from OSM.org data that > existed before your publication and that must be updated. > It's not a matter of how *you* make updates and tag change-sets, > but of how *the mappers* will do it. > They'll File>Upload those updates the normal way, without your > change-sets tags, I don't know how to do it. > > > People are responsible for adding those changeset tags themselves. I don't think they will do it and that it's starting chaos. But chaos and fuzziness are the two udders of OSM, aren't they? > > > If you use *source=survey 2014-06 TEC 2014-04* in bus stops as I > recommend, you will both comply with the source requirement and be > sure to find the indication that they contain your file's data and > can be deleted from the remaining-to-be-updated file. > If an existing element does not contain *source=survey 2014-06** > TEC 2014-04* or later, it will be kept in the > remaining-to-be-updated file. If a mapper further updates the > data, he is kindly requested to use a new date such > as *source=survey 2014-07* or *source=survey 2014-06-21* . > Sorry, it must be *source=survey 2014-04*. > >> As for the operator, I prefer to use simply TEC. > No problem for me with *operator*, but (Sorry Julien, fourth time) > if you use *network*=tec-wl.be <http://tec-wl.be> that's not an > URL and that is not clickable here > <http://www.openstreetmap.org/node/857875464> although we agreed > using an URL (*network*=http://tec-wl.be which is clickable here > <http://www.openstreetmap.org/node/1645537259>) then please add > website=http://tec-wl.be. > > > I don't see the need to add network. Especially if it would be > duplicating what was already in operator. Which entity the stop > belongs to, can be determined in a trivial way from the first letter > of the ref of the stop (for TEC, in the first digit for the stops of > De Lijn). That's what network could be used for, but it's not needed. I didn't speak of adding it. It was already there in the file you published and our wiki says <http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources/TEC#Conventions_d.27encodage> > > Lorsque vous encodez les arrêts de bus "TEC", il est nécessaire de > renseigner les informations suivantes : > > * source <http://wiki.openstreetmap.org/wiki/Key:source>=tec-wl.be > pour indiquer la source de la donnée > * l'opérateur devrait être noté "tec-wl.be", indépendamment du fait > qu'il s'agisse du TEC Wallonie, du TEC Liège ou du TEC > Hoûte-si-plou : operator > <http://wiki.openstreetmap.org/wiki/Key:operator>=tec-wl.be > > > > > > The OSM file with all the stops in Wallonia can be found here: >> https://dl.dropboxusercontent.com/u/42418402/TEC.osm.zip > > I think you should say that it must not be used for updates right now. > > > As always, everybody can use it: 1. at their own risk and on their own > responsability, 2. by double checking everything is correct before > pressing upload. That's what I'm doing at the moment. > > For all the stops I'm adding, I'm double checking the position and the > tags. It's not a matter of simply bulk uploading them. If it were that > simple, I could simply do it in one go. Without any user instructions? > > > >> What we still need to discuss: > The topics mentioned above and > >> Is it OK to keep the zones as 4 digits? For me it's better, as it >> makes them unique. It's not what can be read at the stops in the >> streets though (There you'll find the last 2 digits). > I find the 4 digits all-right because if you don't want to see the > first two you just close your left eye but if they weren't there > and if you wanted to see them it wouldn't be possible ;-) > What do the left two digits mean? Wouldn't that be the place for > the line number? Following "be.wa."? > > > As is often the case. I don't know what you are talking about. The > first 2 digits of the zone number are obviously a way to group zones > which are in the same region. An "area" is a undetermined concept and if a zone is a number of stops for which you pay the same price, then I find natural to group them by line number which is a well determined concept. > I found a new 'problem'. I started adding/editing stops for buses of > TEC which start at Brussels south station. > > 123, 124 and W are from the Brabant-Wallon entity > 365a is from the Charleroi entity. > > All these stops have 2 refs from TEC, so I consider them as 2 stops > which are located at the same position representing them with separate > nodes, as I had started doing for De Lijn and MIVB/STIB. The result is > that some stops are now split into 4 nodes. > > I consider this necessary to make maintenance feasible. But the least > one can say, is that it looks odd... > > I didn't upload yet, so I don't have an example at the moment. It's > quite a bit of work, so it might take me days rather than hours. As is often the case. I don't know what you are talking about. Two bus stops from the same operator at the same place sound like a bug. If you don't see why it is needed to bother TEC with reporting this bug and/or asking what to do, then they provide the data as is and it's our responsibility to convert it to something we can work with. André.
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
