Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

IN OPENSTREETMAP SURVEY MEANS: go out physically, see something with your
own eyes while standing next to it, add it to the DB.

The dictionary definition is not relevant.

Jo


2014-06-23 11:58 GMT+02:00 André Pirard :

>  On 2014-06-17 09:21, Marc Gemis wrote :
>
>
> On Mon, Jun 16, 2014 at 11:13 PM, André Pirard 
> wrote:
>
>> 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, but this is not a survey, this is an import.  IMHO, you can
> only use survey when you go out and check the exact position of the bus
> stop. A survey is not transforming data from one database format into
> another. So please do not use source=survey.
>
> Sorry but it is an import *and* a survey.
>
> *source=TEC 2014-04* relates to the import of the TEC's data*.  **source=TEC
> 2014-04* must be in TEC.osm.zip bus stops so that the mapper copies it to
> OSM. When found in OSM, it means that the bus stop can be removed from the
> file TEC.osm.zip which shows the work that remains to do.  Same process for
> future versions.
>
> * source=survey 2014-xx*  relates to the location, shelter, bench tags
> etc. that the mapper will add at the time of the import or later and it is
> a survey.  It is the last time that this data was verified and it helps
> mappers not to verify what has already been verified.
>
> There should also be a *TEC 2014-04.osm.zip* file containing the original
> TEC data so that the user can compare that data with the data he
> introduces, for example TEC's uppercase name and OSM's lowercase name.
> There will be later files like *TEC 2014-10.osm.zip* at which time a new
> TEC.osm.zip will be created containing the new changes that must be applied.
> The user must also be able to see the lines drawn by TEC in case the bus
> stops do not make the itinerary clear.
> Here is a file of mine:
>
> https://dl.dropboxusercontent.com/s/ty49nmfdb2vfz4m/TEC_2014_04-Lignes.2.osm.bz2
>
> What remains to be done before we can make realistic updates:
>
>- publish *TEC 2014-04.osm.zip* (= present TEC.osm.zip + following
>tags)
> - add *source=TEC 2014-04* to *TEC 2014-04.osm.zip*
>- add *source=survey 2014-04* to *TEC 2014-04.osm.zip*
>- add website tag
> - new TEC.osm.zip = *TEC 2014-04.osm.zip*
>- new *TEC 2014-04.lines.osm.zip*
>
> Please note that the particular syntax of the tags is moot.
> But, please, make propositions instead of saying what it must not be
> (there are just too many).
>
> I can publish a "how to tag the bus stops" in the wiki page if you like.
>  On 2014-06-17 15:19, Ben Abelshausen wrote :
>
>
> On Tue, Jun 17, 2014 at 3:16 PM, Marc Gemis  wrote:
>
>> the source should a) contain some reference to TEC,
>>
>  Exactly!
>
>
> And (a) is "Exactly! " what *source=TEC 2014-04* was proposing.
>
>
> b) any aerial image you have used (probably Bing).
>
>
> This is something that everybody knows, or should know. "Bing 2004" or so,
> not "Bing".
>
>
>  you can only use survey when you go out
>
>
> On 2014-06-17 15:18, Ben Abelshausen wrote :
>
>  "Survey" does mean explicitly that there was an actual survey (meaning,
> going to each and every bus station to check if it is there!):
> http://wiki.openstreetmap.org/wiki/Survey#How_to_use
>
> That article does not define "Survey" explicitly. It says that it is a
> survey.
>
> dictionary.reference.com 
>
> to view in detail, especially to inspect, examine, or appraise formally or
> officially in order to ascertain condition, value, etc.
> appraise:  to estimate the nature, quality, importance, etc.:
>
> Nothing in that says that the surveyor must travel.  Any means to
> ascertain the data is acceptable.
>
> Cordialement,
>
>   André.
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

Since I would prefer to keep things simple, or at least as simple as
possible, I'd prefer to work with one file.

To indicate that a stop is not in Openstreetmap yet, I tag it with odbl=new
when no stop with its ref is in the file I download from Overpass API.

This tag will be stripped automatically by JOSM before the data gets
uploaded, just like the created_by tag which I use to make street names
available to the person doing the import. They don't make sense in the
Brabant-Wallon file, but they seem to have helpful information in the
Charleroi file.

Since I'm a minimalist who'd prefer to put as few tags possible on stops,
platforms, stop positions, shelters, benches and waste baskets, I'd prefer
not to add source tags on each and every of the 7x? objects we'll be
adding to the DB. OK, I counted the stops of De Lijn in that number.

So I add source information on the changesets, which is the accepted
practice nowadays, at least that's what I read on the imports list.

If you want to add such tags, you can open the file, Ctrl-a to select all
objects. Add the tags you want and save the file.

Jo




2014-06-23 11:58 GMT+02:00 André Pirard :

>  On 2014-06-17 09:21, Marc Gemis wrote :
>
>
> On Mon, Jun 16, 2014 at 11:13 PM, André Pirard 
> wrote:
>
>> 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, but this is not a survey, this is an import.  IMHO, you can
> only use survey when you go out and check the exact position of the bus
> stop. A survey is not transforming data from one database format into
> another. So please do not use source=survey.
>
> Sorry but it is an import *and* a survey.
>
> *source=TEC 2014-04* relates to the import of the TEC's data*.  **source=TEC
> 2014-04* must be in TEC.osm.zip bus stops so that the mapper copies it to
> OSM. When found in OSM, it means that the bus stop can be removed from the
> file TEC.osm.zip which shows the work that remains to do.  Same process for
> future versions.
>
> * source=survey 2014-xx*  relates to the location, shelter, bench tags
> etc. that the mapper will add at the time of the import or later and it is
> a survey.  It is the last time that this data was verified and it helps
> mappers not to verify what has already been verified.
>
> There should also be a *TEC 2014-04.osm.zip* file containing the original
> TEC data so that the user can compare that data with the data he
> introduces, for example TEC's uppercase name and OSM's lowercase name.
> There will be later files like *TEC 2014-10.osm.zip* at which time a new
> TEC.osm.zip will be created containing the new changes that must be applied.
> The user must also be able to see the lines drawn by TEC in case the bus
> stops do not make the itinerary clear.
> Here is a file of mine:
>
> https://dl.dropboxusercontent.com/s/ty49nmfdb2vfz4m/TEC_2014_04-Lignes.2.osm.bz2
>
> What remains to be done before we can make realistic updates:
>
>- publish *TEC 2014-04.osm.zip* (= present TEC.osm.zip + following
>tags)
> - add *source=TEC 2014-04* to *TEC 2014-04.osm.zip*
>- add *source=survey 2014-04* to *TEC 2014-04.osm.zip*
>- add website tag
> - new TEC.osm.zip = *TEC 2014-04.osm.zip*
>- new *TEC 2014-04.lines.osm.zip*
>
> Please note that the particular syntax of the tags is moot.
> But, please, make propositions instead of saying what it must not be
> (there are just too many).
>
> I can publish a "how to tag the bus stops" in the wiki page if you like.
>  On 2014-06-17 15:19, Ben Abelshausen wrote :
>
>
> On Tue, Jun 17, 2014 at 3:16 PM, Marc Gemis  wrote:
>
>> the source should a) contain some reference to TEC,
>>
>  Exactly!
>
>
> And (a) is "Exactly! " what *source=TEC 2014-04* was proposing.
>
>
> b) any aerial image you have used (probably Bing).
>
>
> This is something that everybody knows, or should know. "Bing 2004" or so,
> not "Bing".
>
>
>  you can only use survey when you go out
>
>
> On 2014-06-17 15:18, Ben Abelshausen wrote :
>
>  "Survey" does mean explicitly that there was an actual survey (meaning,
> going to each and every bus station to check if it is there!):
> http://wiki.openstreetmap.org/wiki/Survey#How_to_use
>
> That article does not define "Survey" explicitly. It says that it is a
> survey.
>
> dictionary.reference.com 
>
> to view in detail, especially to inspect, examine, or appraise formally or
> officially in order to ascertain condition, value, etc.
> appraise:  to esti

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

  
  
On 2014-06-17 09:21, Marc Gemis wrote :


  

  On Mon, Jun 16, 2014 at 11:13 PM,
André Pirard 
wrote:

  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, but this is not a survey, this is an import.  IMHO, you
  can only use survey when you go out and check the exact
  position of the bus stop. A survey is not transforming data
  from one database format into another. So please do not use
  source=survey.
  

Sorry but it is an import and a survey.

source=TEC 2014-04 relates to the import of the TEC's data. 
source=TEC 2014-04 must be in TEC.osm.zip bus stops so
that the mapper copies it to OSM. When found in OSM, it means that
the bus stop can be removed from the file TEC.osm.zip which shows
the work that remains to do.  Same process for future versions.

  source=survey 2014-xx  relates to the location, shelter, bench
tags etc. that the mapper will add at the time of the import or
later and it is a survey.  It is the last time that this data was
verified and it helps mappers not to verify what has already been
verified.

There should also be a TEC 2014-04.osm.zip file containing
the original TEC data so that the user can compare that data with
the data he introduces, for example TEC's uppercase name and OSM's
lowercase name.
There will be later files like TEC 2014-10.osm.zip at which
time a new TEC.osm.zip will be created containing the new changes
that must be applied.
The user must also be able to see the lines drawn by TEC in case the
bus stops do not make the itinerary clear.
Here is a file of mine:
https://dl.dropboxusercontent.com/s/ty49nmfdb2vfz4m/TEC_2014_04-Lignes.2.osm.bz2

What remains to be done before we can make realistic updates:

  publish TEC 2014-04.osm.zip (= present TEC.osm.zip +
following tags)
  
  add source=TEC 2014-04 to TEC 2014-04.osm.zip
  add source=survey 2014-04 to TEC
  2014-04.osm.zip
  add website tag
  
  new TEC.osm.zip = TEC 2014-04.osm.zip
  new TEC 2014-04.lines.osm.zip

Please note that the particular syntax of the tags is moot.
  But, please, make propositions instead of saying what it must not
  be (there are just too many).

I can publish a "how to tag the bus stops" in the wiki page if
  you like.

On 2014-06-17 15:19, Ben Abelshausen
  wrote :


  

  On Tue, Jun 17, 2014 at 3:16 PM, Marc
Gemis 
wrote:

  the
source should a) contain some reference to TEC,
  

  
  Exactly!

  


And (a) is "Exactly!
" what source=TEC 2014-04 was proposing.

b)
  any aerial image you have used (probably Bing).


This is something that everybody knows, or should know. "Bing 2004"
or so, not "Bing".

 you can only use survey when you go out

On 2014-06-17 15:18, Ben Abelshausen
  wrote :


  
"Survey" does mean explicitly that there was an actual
  survey (meaning, going to each and every bus station to check
  if it is there!):
http://wiki.openstreetmap.org/wiki/Survey#How_to_use
  

That article does not define "Survey" explicitly. It says that it is
a survey.

dictionary.reference.com

  to
  view in detail,
  especially to inspect,
  examine, or appraise formally or officially
  in order to ascertain
  condition, value, etc.
  appraise:  to
  estimate
  the nature, quality, importance,
  etc.: 
  

Nothing in that says that the surveyor must travel.  Any means to
ascertain the data is acceptable.

Cordialement,


  

  André.

  



  


___

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-18 23:12, Jo wrote :
> I posted on the imports list. This is the first answer I got:
>
> Hi,
>
> I'm sorry to bear bad news, but the "sharealike" aspect of CC-BY-SA
> 4.0 means that you cannot import the data into OSM, since CC-BY-SA 4.0
> data can be publicly adapted only under ___the same___ licence (i.e.
> not under OSM's ODbL licence) - or, more accurately, it must be
> publicly reused one of the licences listed in the first section of
> this page:
> https://creativecommons.org/compatiblelicenses
>
> Dan
>
>
>
> Can we ask TEC directly to give Openstreetmap explicit permission to
> reuse the data and redistribute as ODbL? Or whether they'd consider
> releasing the data under ODbL as well?
>
> Do we have a contact with them who can make such decisions?
PATRIS Antoine 
I cc:ed you a reply in which he was very cooperative and he implicitly
agreed that we use their data.
He's the GIS project manager.
You said "why bother them?" ;-)
I hope it's the only grief from Dan.
Я могу исправить французский.

Thanks.
In'ch Allah.

André.


> Jo
>
>
> 2014-06-18 15:18 GMT+02:00 Jo  >:
>
> I managed to get the script to the next 'level'. For lines for
> which all stops are mapped, it's possible to create skeleton route
> relations for all the variations.
>
> See here for an example:
>
> 
> https://dl.dropboxusercontent.com/u/42418402/RoutesFor%20W%20BXL%20-%20Waterloo.osm
>
> Give me a sign if you plan to actually use it. If you do, keep in
> mind 2 routes already exist for that line, which I created by
> adding the stops manually. Those 2 contain ways too, of course. It
> takes a bit of fiddling to add them to the route_master and
> transfer the stops from 2 of the skeleton routes to them.
>
> If you want other skeleton routes to experiment with, let me know.
> It's easier when no routes for such a line exist yet in the OSM
> data. But then you still have to add all the composing ways
> yourself, of course. In the MAPCSS I have code to visually
> highlight all the stops when you temporarily add odbl=yes as a tag
> to the route.
>
> For those interested in the subject, I think it's best to simply
> show it all during a Google hangout.
>
> Cheers,
>
> Jo
>
>
> 2014-06-17 23:20 GMT+02:00 André Pirard  >:
>
> On 2014-06-17 22:41, Jo wrote :
>> What I fail to see is why I'd need to contact him. It doesn't
>> depend on him at all whether the import is approved or not.
> No but he probably knows much about how being approved and
> it's his interest to help you
>
>> Anyway, the question is: Is that wiki page good enough for
>> submitting it or does it need to be improved?
> and he might know that. Not me.
>
> Up to you (but please help my finger cramp ;-))
>
> André.
>
>
>>
>> Jo
>>
>>
>> 2014-06-17 22:07 GMT+02:00 André Pirard
>> mailto:a.pirard.pa...@gmail.com>>:
>>
>> Jo,
>>
>> Isn't Andy Allan making the Transport Map?
>> You might try to get advice from him.
>> He would certainly be keen to have us on his map!
>> I once contacted him for a bike map trifle.
>> Took some time but he very kindly replied.
>> Whoever that is anyway.
>>
>> Fingers crossed.
>>
>> André.
>>
>>
>>
>>
>
>
>

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Pieter Colpaert]

Share-Alike doesn't make much sense for data. Agree we should ask TEC to 
go for CC BY or CC 0.


Kind regards,

Pieter
On 2014-06-18 23:12, Jo wrote:

I posted on the imports list. This is the first answer I got:

Hi,

I'm sorry to bear bad news, but the "sharealike" aspect of CC-BY-SA
4.0 means that you cannot import the data into OSM, since CC-BY-SA 4.0
data can be publicly adapted only under ___the same___ licence (i.e.
not under OSM's ODbL licence) - or, more accurately, it must be
publicly reused one of the licences listed in the first section of
this page:
https://creativecommons.org/compatiblelicenses

Dan



Can we ask TEC directly to give Openstreetmap explicit permission to 
reuse the data and redistribute as ODbL? Or whether they'd consider 
releasing the data under ODbL as well?


Do we have a contact with them who can make such decisions?

Jo


2014-06-18 15:18 GMT+02:00 Jo >:


I managed to get the script to the next 'level'. For lines for
which all stops are mapped, it's possible to create skeleton route
relations for all the variations.

See here for an example:


https://dl.dropboxusercontent.com/u/42418402/RoutesFor%20W%20BXL%20-%20Waterloo.osm

Give me a sign if you plan to actually use it. If you do, keep in
mind 2 routes already exist for that line, which I created by
adding the stops manually. Those 2 contain ways too, of course. It
takes a bit of fiddling to add them to the route_master and
transfer the stops from 2 of the skeleton routes to them.

If you want other skeleton routes to experiment with, let me know.
It's easier when no routes for such a line exist yet in the OSM
data. But then you still have to add all the composing ways
yourself, of course. In the MAPCSS I have code to visually
highlight all the stops when you temporarily add odbl=yes as a tag
to the route.

For those interested in the subject, I think it's best to simply
show it all during a Google hangout.

Cheers,

Jo


2014-06-17 23:20 GMT+02:00 André Pirard mailto:a.pirard.pa...@gmail.com>>:

On 2014-06-17 22:41, Jo wrote :

What I fail to see is why I'd need to contact him. It doesn't
depend on him at all whether the import is approved or not.

No but he probably knows much about how being approved and
it's his interest to help you


Anyway, the question is: Is that wiki page good enough for
submitting it or does it need to be improved?

and he might know that. Not me.

Up to you (but please help my finger cramp ;-))

André.




Jo


2014-06-17 22:07 GMT+02:00 André Pirard
mailto:a.pirard.pa...@gmail.com>>:

Jo,

Isn't Andy Allan making the Transport Map?
You might try to get advice from him.
He would certainly be keen to have us on his map!
I once contacted him for a bike map trifle.
Took some time but he very kindly replied.
Whoever that is anyway.

Fingers crossed.

André.










--

+32 486 74 71 22

Open Knowledge Foundation Belgium
http://okfn.be

Open Transport Working Group OKFN
http://transport.okfn.org

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

I posted on the imports list. This is the first answer I got:

Hi,
>
> I'm sorry to bear bad news, but the "sharealike" aspect of CC-BY-SA
> 4.0 means that you cannot import the data into OSM, since CC-BY-SA 4.0
> data can be publicly adapted only under ___the same___ licence (i.e.
> not under OSM's ODbL licence) - or, more accurately, it must be
> publicly reused one of the licences listed in the first section of
> this page:
> https://creativecommons.org/compatiblelicenses
>
> Dan
>


Can we ask TEC directly to give Openstreetmap explicit permission to reuse
the data and redistribute as ODbL? Or whether they'd consider releasing the
data under ODbL as well?

Do we have a contact with them who can make such decisions?

Jo


2014-06-18 15:18 GMT+02:00 Jo :

> I managed to get the script to the next 'level'. For lines for which all
> stops are mapped, it's possible to create skeleton route relations for all
> the variations.
>
> See here for an example:
>
>
> https://dl.dropboxusercontent.com/u/42418402/RoutesFor%20W%20BXL%20-%20Waterloo.osm
>
> Give me a sign if you plan to actually use it. If you do, keep in mind 2
> routes already exist for that line, which I created by adding the stops
> manually. Those 2 contain ways too, of course. It takes a bit of fiddling
> to add them to the route_master and transfer the stops from 2 of the
> skeleton routes to them.
>
> If you want other skeleton routes to experiment with, let me know. It's
> easier when no routes for such a line exist yet in the OSM data. But then
> you still have to add all the composing ways yourself, of course. In the
> MAPCSS I have code to visually highlight all the stops when you temporarily
> add odbl=yes as a tag to the route.
>
> For those interested in the subject, I think it's best to simply show it
> all during a Google hangout.
>
> Cheers,
>
> Jo
>
>
> 2014-06-17 23:20 GMT+02:00 André Pirard :
>
>  On 2014-06-17 22:41, Jo wrote :
>>
>>  What I fail to see is why I'd need to contact him. It doesn't depend on
>> him at all whether the import is approved or not.
>>
>> No but he probably knows much about how being approved and it's his
>> interest to help you
>>
>>  Anyway, the question is: Is that wiki page good enough for submitting
>> it or does it need to be improved?
>>
>> and he might know that. Not me.
>>
>> Up to you (but please help my finger cramp ;-))
>>
>>   André.
>>
>>
>>  Jo
>>
>>
>> 2014-06-17 22:07 GMT+02:00 André Pirard :
>>
>>>  Jo,
>>>
>>> Isn't Andy Allan making the Transport Map?
>>> You might try to get advice from him.
>>> He would certainly be keen to have us on his map!
>>> I once contacted him for a bike map trifle.
>>> Took some time but he very kindly replied.
>>> Whoever that is anyway.
>>>
>>> Fingers crossed.
>>>
>>>   André.
>>>
>>>
>>
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

I managed to get the script to the next 'level'. For lines for which all
stops are mapped, it's possible to create skeleton route relations for all
the variations.

See here for an example:

https://dl.dropboxusercontent.com/u/42418402/RoutesFor%20W%20BXL%20-%20Waterloo.osm

Give me a sign if you plan to actually use it. If you do, keep in mind 2
routes already exist for that line, which I created by adding the stops
manually. Those 2 contain ways too, of course. It takes a bit of fiddling
to add them to the route_master and transfer the stops from 2 of the
skeleton routes to them.

If you want other skeleton routes to experiment with, let me know. It's
easier when no routes for such a line exist yet in the OSM data. But then
you still have to add all the composing ways yourself, of course. In the
MAPCSS I have code to visually highlight all the stops when you temporarily
add odbl=yes as a tag to the route.

For those interested in the subject, I think it's best to simply show it
all during a Google hangout.

Cheers,

Jo


2014-06-17 23:20 GMT+02:00 André Pirard :

>  On 2014-06-17 22:41, Jo wrote :
>
>  What I fail to see is why I'd need to contact him. It doesn't depend on
> him at all whether the import is approved or not.
>
> No but he probably knows much about how being approved and it's his
> interest to help you
>
>  Anyway, the question is: Is that wiki page good enough for submitting it
> or does it need to be improved?
>
> and he might know that. Not me.
>
> Up to you (but please help my finger cramp ;-))
>
>   André.
>
>
>  Jo
>
>
> 2014-06-17 22:07 GMT+02:00 André Pirard :
>
>>  Jo,
>>
>> Isn't Andy Allan making the Transport Map?
>> You might try to get advice from him.
>> He would certainly be keen to have us on his map!
>> I once contacted him for a bike map trifle.
>> Took some time but he very kindly replied.
>> Whoever that is anyway.
>>
>> Fingers crossed.
>>
>>   André.
>>
>>
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-17 22:41, Jo wrote :
> What I fail to see is why I'd need to contact him. It doesn't depend
> on him at all whether the import is approved or not.
No but he probably knows much about how being approved and it's his
interest to help you
> Anyway, the question is: Is that wiki page good enough for submitting
> it or does it need to be improved?
and he might know that. Not me.

Up to you (but please help my finger cramp ;-))

André.


>
> Jo
>
>
> 2014-06-17 22:07 GMT+02:00 André Pirard  >:
>
> Jo,
>
> Isn't Andy Allan making the Transport Map?
> You might try to get advice from him.
> He would certainly be keen to have us on his map!
> I once contacted him for a bike map trifle.
> Took some time but he very kindly replied.
> Whoever that is anyway.
>
> Fingers crossed.
>
> André.
>
>
>
>

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-17 21:58, Jo wrote :
> The way I always understood the word survey in an OSM context is
> physically going somewhere, recording a fact about the geography and
> adding it to Openstreetmap. The job of a surveyor. I guess it's OK to
> send somebody else who takes picture or adds POIs for you.
One of the BIG OSM problem is that the wiki does not define survey and
other words at all and that the dictionaries contain up to 12
definitions for them.
My big problem is that I can't think like those who tell me that I have
to learn that OSM is fuzzy, or think that if a GPS tells me to turn
right I might have to turn left, and that people laugh at me when I
believe that it could be done correctly.
In this case, I will give up doing more than considering that the data
source is TEC, please Jo make sure that your file contains source=*TEC
2014-04* so that we didn't have to type it every time and that we do all
the same.

André.


PS: sorry for a duplicate post to a few.

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

All the routes that we add in the proper way are on his transport map
automatically. Look at Flanders. Oost-Vlaanderen is as good as complete.
The eastern part of Vlaams-Brabant as well. Many lines in Limburg are also
mapped.

I recently added 1 between LLN and Jodoigne, line 20 between Wavre and LLN.
18 between Leuven and Jodoigne was already there (manual labour), now it's
improved with all the detail and a second variation. Today I added lines
between Brussels and Waterloo/Charleroi. And this evening I moved over to
Tienen. Line 5 between Tienen and Jodoigne will probably show up on Andy's
map by tomorrow.

What I fail to see is why I'd need to contact him. It doesn't depend on him
at all whether the import is approved or not.

Anyway, the question is: Is that wiki page good enough for submitting it or
does it need to be improved?

Jo


2014-06-17 22:07 GMT+02:00 André Pirard :

>  Jo,
>
> Isn't Andy Allan making the Transport Map?
> You might try to get advice from him.
> He would certainly be keen to have us on his map!
> I once contacted him for a bike map trifle.
> Took some time but he very kindly replied.
> Whoever that is anyway.
>
> Fingers crossed.
>
>   André.
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-17 15:16, Marc Gemis wrote :
> From http://wiki.openstreetmap.org/wiki/Map_Features#Annotation
>
> source = survey Track from GPS unit (usually GPX fomat) or other
> physical survey; suggested addition - survey:date
> =-MM-DD
>
> so IMHO checking the position on aerial images is not included

According to Key:source ,

  * survey = see above in section "How To Use"
  * "How To Use": a survey is a survey, a survey is a survey, 
  * and, according to the dictionary, survey = "*to inspect*  to view in
detail, ... *in order to ascertain* condition, value, etc."
  * I doubt that "source:maxspeed
=Survey 20
November 2012" was done with a "GPS unit (usually GPX fomat) or
other physical survey":  your quote is incoherent with Key:source

  * in source:XXX=data, XXX is whose key (its name) source applies to
and data is the means of verification like visual and survey,
including any reference to a publication. When XXX does not exist,
source applies to all tags.
  * there is no XXX specific to precise location indeed.

So, to my best understanding of English, *source=survey 2014-04* means
that all data have been verified to be correct on that date.

_And that's exactly my intention to indicate that all the data of a bus
stop entry has been verified_ to spare the next visitor another useless
verification.

It may happen that there is an error in a TEC entry and, in that case,
the survey date will be later than the import date and a note had better
explain why.
BTW, this has been presented on the Tagging@osm list and nobody denied
the meaning of survey, only someone said that he doesn't like the word
"survey" for that purpose.

Now if you know a better way, don't hesitate to start suggesting.
> the source should a) contain some reference to TEC,
and what do you think is *TEC 2014-04*?
or Julien's  http://tec-wl.be 2014-04 instead?

But, as we say, Jo should include that in his file.

> b) any aerial image you have used (probably Bing).
all I said doesn't exclude other sources like *Bing 2004* nor anything
else of http://wiki.openstreetmap.org
but I will not make an exhaustive list of what mappers are supposed to
know already

On 2014-06-17 15:18, Ben Abelshausen wrote :
> "Survey" does mean explicitly that there was an actual survey
> (meaning, going to each and every bus station to check if it is
> there!): http://wiki.openstreetmap.org/wiki/Survey#How_to_use

Survey meaning that there was a survey makes no doubt, but the problem
is defining the word survey which, typically OSM, that article does not.
So, I resorted to a dictionary and it it's a verification by any means,
not necessarily going.

Checking if it's there, and I'll add "where".
Actually, a plain bus stop is where the bus stops. So, having no bus
stop simply means that the bus doesn't stop.
If TEC says that the bus stops, I have a tendency to believe them, else
who should we believe? ;-)
Now, regarding the shelters, shoulders etc., and exact position, the
police have surveillance cameras to check that no one stole the street. 
But we, penniless people, have satellites to check that no one stole bus
stops ;-)  In the north, no problem using them.  In the south, it needs
some trickery because we cannot copy (yet) orthophotos. The trickery is
to find the bus stop on a viewable-only, recent photo, then to check
that it's at the same place as on Bing, and then to copy it from Bing. 
Et voilà.
In the rare cases you must go, you can go by bus. Use a delivery
itinerary optimizer and a GPS tracker and buy a round trip tourist
ticket.  Ask the driver if he prefers telling you where he would stop
exactly or if you're required to actually push the stop button each time.

BTW, I have read that it's the way they make their maps. By running
trackers on drivers' GPSes and calculating the mean values.  According
to the results obtained by TEC, I would recommend buying several round
trip tickets ;-)

Just a little bit humorously ;-)

André.


> regards
>
> m
>
>
> On Tue, Jun 17, 2014 at 2:55 PM, André Pirard
> mailto:a.pirard.pa...@gmail.com>> wrote:
>
> On 2014-06-17 09:21, Marc Gemis wrote :
>>
>> On Mon, Jun 16, 2014 at 11:13 PM, André Pirard
>> mailto:a.pirard.pa...@gmail.com>> wrote:
>>
>> 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, 

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

Jo,

Isn't Andy Allan making the Transport Map?
You might try to get advice from him.
He would certainly be keen to have us on his map!
I once contacted him for a bike map trifle.
Took some time but he very kindly replied.
Whoever that is anyway.

Fingers crossed.

André.



___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

The way I always understood the word survey in an OSM context is physically
going somewhere, recording a fact about the geography and adding it to
Openstreetmap. The job of a surveyor. I guess it's OK to send somebody else
who takes picture or adds POIs for you.

Jo




2014-06-17 21:49 GMT+02:00 André Pirard :

>  On 2014-06-17 15:16, Marc Gemis wrote :
>
> From http://wiki.openstreetmap.org/wiki/Map_Features#Annotation
>
>  source = survey Track from GPS unit (usually GPX fomat) or other
> physical survey; suggested addition - survey:date
> =-MM-DD
>
>  so IMHO checking the position on aerial images is not included
>
>
> According to Key:source ,
>
>- survey = see above in section "How To Use"
>- "How To Use": a survey is a survey, a survey is a survey,
>- and, according to the dictionary, survey = "*to inspect*  to view in
>detail, ... *in order to ascertain* condition, value, etc."
> - I doubt that "source:maxspeed
>=Survey 20
>November 2012" was done with a "GPS unit (usually GPX fomat) or other
>physical survey":  your quote is incoherent with Key:source
>
>- in source:XXX=data, XXX is whose key (its name) source applies to
>and data is the means of verification like visual and survey, including any
>reference to a publication. When XXX does not exist, source applies to all
>tags.
>- there is no XXX specific to precise location indeed.
>
> So, to my best understanding of English, *source=survey 2014-04* means
> that all data have been verified to be correct on that date.
>
> *And that's exactly my intention to indicate that all the data of a bus
> stop entry has been verified* to spare the next visitor another useless
> verification.
>
> It may happen that there is an error in a TEC entry and, in that case, the
> survey date will be later than the import date and a note had better
> explain why.
> BTW, this has been presented on the Tagging@osm list and nobody denied
> the meaning of survey, only someone said that he doesn't like the word
> "survey" for that purpose.
>
> Now if you know a better way, don't hesitate to start suggesting.
>
>  the source should a) contain some reference to TEC,
>
> and what do you think is *TEC 2014-04*?
> or Julien's  http://tec-wl.be 2014-04 instead?
>
> But, as we say, Jo should include that in his file.
>
>
>   b) any aerial image you have used (probably Bing).
>
> all I said doesn't exclude other sources like *Bing 2004* nor anything
> else of http://wiki.openstreetmap.org
> but I will not make an exhaustive list of what mappers are supposed to
> know already
>
> On 2014-06-17 15:18, Ben Abelshausen wrote :
>
>  "Survey" does mean explicitly that there was an actual survey (meaning,
> going to each and every bus station to check if it is there!):
> http://wiki.openstreetmap.org/wiki/Survey#How_to_use
>
>
> Survey meaning that there was a survey makes no doubt, but the problem is
> defining the word survey which, typically OSM, that article does not. So, I
> resorted to a dictionary and it it's a verification by any means, not
> necessarily going.
>
> Checking if it's there, and I'll add "where".
> Actually, a plain bus stop is where the bus stops. So, having no bus stop
> simply means that the bus doesn't stop.
> If TEC says that the bus stops, I have a tendency to believe them, else
> who should we believe? ;-)
> Now, regarding the shelters, shoulders etc., and exact position, the
> police have surveillance cameras to check that no one stole the street.
> But we, penniless people, have satellites to check that no one stole bus
> stops ;-)  In the north, no problem using them.  In the south, it needs
> some trickery because we cannot copy (yet) orthophotos. The trickery is to
> find the bus stop on a viewable-only, recent photo, then to check that it's
> at the same place as on Bing, and then to copy it from Bing.  Et voilà.
> In the rare cases you must go, you can go by bus. Use a delivery itinerary
> optimizer and a GPS tracker and buy a round trip tourist ticket.  Ask the
> driver if he prefers telling you where he would stop exactly or if you're
> required to actually push the stop button each time.
>
> BTW, I have read that it's the way they make their maps. By running
> trackers on drivers' GPSes and calculating the mean values.  According to
> the results obtained by TEC, I would recommend buying several round trip
> tickets ;-)
>
> Just a little bit humorously ;-)
>
>   André.
>
>  regards
>
>  m
>
>
> On Tue, Jun 17, 2014 at 2:55 PM, André Pirard 
> wrote:
>
>>  On 2014-06-17 09:21, Marc Gemis wrote :
>>
>>
>> On Mon, Jun 16, 2014 at 11:13 PM, André Pirard 
>> wrote:
>>
>>> If you use *source=survey 2014-06  TEC 2014-04* in bus stops as I
>>> recommend, you will both comply with the source requireme

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

It's a lot of data and it's coming from an outside source, so yes it's an
import. No way to get around that by calling it anything different. It's
best to go through the proper channels. That way nobody can say we didn't
at least try to do things the right way.

If we fall flat on our noses, so be it. I had always thought data like this
is (and addresses) is something we want to have in OSM. And visiting each
bus stop (or house) is simply not practical. By the time you did all of
them, you'd have to start over again.

I do agree sometimes imports hurt the community, which is why I'd like to
get the community involved as much as possible.

I also think we're going about this the right way. This is not a data dump.
We are integrating the new data with what's already present in OSM. I often
find myself improving the topology of the roads while adding stops and
shelters and benches and platforms. For Flanders we have now the street
names in a WMS layer, so during validation I'm also adding those for the
roads I touched (adding nodes or splitting).

Unfortunately it's extremely time consuming to do it this way, but it's
still more efficient than visiting 7 bus stops all across the country
and jotting down their details.

Jo


2014-06-17 21:27 GMT+02:00 André Pirard :

>  On 2014-06-17 20:15, Jo wrote :
>
>   I created a page to describe the import of TEC data. Can somebody have
> a look at it before I send it to the imports mailing list?
>
> http://wiki.openstreetmap.org/wiki/PT_TEC_Wallonie_BE_Import
>
>  I have to say I'm a bit pessimistic about getting it approved. I've been
> lurking on the imports list for a while now and it's a bit depressing...
>
>  But we can always try, of course. Even though I realise in advance it
> will get shot down on the silly dedicated import account rule alone.
>
> Ouch!  I didn't expect that difficulty!
>
> But I have a very fundamental remark.
> Are you really doing an import or are you providing us modified data to
> ease our tagging?
> Would using Julien's web page be called an import?
> Is making the process easier more an import?
> Was the Walloon bus line tagging done so far an import?
> Is continuing it more an import?
>
> I never looked a that problem but I think that what they're after is huge
> careless data dumping.
> It's none of that.
>
> So my question is: must we really declare that as an import
> or continue our gentle tagging business on the quiet?
> Why tempting fate?
>
>
>   In the mean time I'm doing test edits, to make sure the data conversion
> went properly. It looks fine, as far as I'm concerned. Some abbreviations
> don't get expanded properly yet (notably ones with a space after LE). I do
> those by hand. Whoever wants to participate in adding these stops must
> realise it not simply a matter of dragging them to their proper location,
> but also the names need to be checked for consistency.
>
> I told you I had thought of picking the names from OSM inside a circle
> around the stop and checking the uppercase for similarity.  There's a Perl
> string similarity computing module.  Did you consider that?
>
>   The zones and the calculated route_refs should be correct by now. The
> village names are mostly properly converted and accents are put back where
> they belong. Notify me if you find errors.
>
>  I'm always prepared to do a Google hangout in French, English or even
> Dutch (for those who'd want to practice) to explain how I set up JOSM to
> make the whole process more efficient. Additional buttons on the task bar
> for presets and searches. dedicated MAPCSS style, which highlights the
> stops and routes you are working on and something which creates display
> names from distinct tags, so the routes get sorted in a better way in the
> relations list.
>
>
> Good luck whatever you do,
>
>   André.
>
>
>
>
>
>  Cheers,
>
>  Polyglot
>
>
> 2014-06-17 15:18 GMT+02:00 Ben Abelshausen :
>
>> Hi,
>>
>>  "Survey" does mean explicitly that there was an actual survey (meaning,
>> going to each and every bus station to check if it is there!):
>>
>>  http://wiki.openstreetmap.org/wiki/Survey#How_to_use
>>
>>  Also make sure to check the import guidelines before importing anything:
>>
>>  http://wiki.openstreetmap.org/wiki/Import/Guidelines
>>
>>   Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-17 20:15, Jo wrote :
> I created a page to describe the import of TEC data. Can somebody have
> a look at it before I send it to the imports mailing list?
>
> http://wiki.openstreetmap.org/wiki/PT_TEC_Wallonie_BE_Import
>
> I have to say I'm a bit pessimistic about getting it approved. I've
> been lurking on the imports list for a while now and it's a bit
> depressing...
>
> But we can always try, of course. Even though I realise in advance it
> will get shot down on the silly dedicated import account rule alone.
Ouch!  I didn't expect that difficulty!

But I have a very fundamental remark.
Are you really doing an import or are you providing us modified data to
ease our tagging?
Would using Julien's web page be called an import?
Is making the process easier more an import?
Was the Walloon bus line tagging done so far an import?
Is continuing it more an import?

I never looked a that problem but I think that what they're after is
huge careless data dumping.
It's none of that.

So my question is: must we really declare that as an import
or continue our gentle tagging business on the quiet?
Why tempting fate?

> In the mean time I'm doing test edits, to make sure the data
> conversion went properly. It looks fine, as far as I'm concerned. Some
> abbreviations don't get expanded properly yet (notably ones with a
> space after LE). I do those by hand. Whoever wants to participate in
> adding these stops must realise it not simply a matter of dragging
> them to their proper location, but also the names need to be checked
> for consistency.
I told you I had thought of picking the names from OSM inside a circle
around the stop and checking the uppercase for similarity.  There's a
Perl string similarity computing module.  Did you consider that?
> The zones and the calculated route_refs should be correct by now. The
> village names are mostly properly converted and accents are put back
> where they belong. Notify me if you find errors.
>
> I'm always prepared to do a Google hangout in French, English or even
> Dutch (for those who'd want to practice) to explain how I set up JOSM
> to make the whole process more efficient. Additional buttons on the
> task bar for presets and searches. dedicated MAPCSS style, which
> highlights the stops and routes you are working on and something which
> creates display names from distinct tags, so the routes get sorted in
> a better way in the relations list.

Good luck whatever you do,

André.





>
> Cheers,
>
> Polyglot
>
>
> 2014-06-17 15:18 GMT+02:00 Ben Abelshausen  >:
>
> Hi,
>
> "Survey" does mean explicitly that there was an actual survey
> (meaning, going to each and every bus station to check if it is
> there!):
>
> http://wiki.openstreetmap.org/wiki/Survey#How_to_use
>
> Also make sure to check the import guidelines before importing
> anything:
>
> http://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

Julien,

Peux-tu vérifier si je n'ai pas fais trop de bêtises en adaptant cette page:

http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources/TEC

Jo


2014-04-25 8:26 GMT+02:00 Julien Fastré :

> Hi !
>
> Good news ! (Alleluia :-) )
>
> The TEC is publishing now data under Open Data Licence !
>
> On geoportail.wallonie.be, the data "Poteaux d'arrêts" (bus stop) and
> "ligne de bus" (bus lines) are now under CC BY-SA 4.0 international
> Licence :
>
>
> http://geoportail.wallonie.be/geocatalogue?mdUUID=47676af7-aab3-4d2e-9c9c-cd86e7ad7241
>
> http://geoportail.wallonie.be/geocatalogue?mdUUID=a5dc5bc7-3c37-4783-9c41-27ce2f83f3ae
>
> The schedules are also available here :
> http://opendata.awt.be/organization/groupe-tec (in a "Belgian format"...
> glups... I still haven't opened it yet).
>
> We are now allowed to import those data's in OSM.
>
> Please, do not batch import ! I saw in the previous version a lot of
> mistakes, comparing data to Bing! Imagery and also to Walloon's
> orthophotos. We may be more accurate than the original data :-)
>
> At Champs Libres, we are planning to provide an online "comparator" from
> TEC data to OSM data, using the old and new public transport schema.
> This will allow to see where are missing bus stops, where they are
> mispelled, etc. We will do it during May.
>
> Julien
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

I created a page to describe the import of TEC data. Can somebody have a
look at it before I send it to the imports mailing list?

http://wiki.openstreetmap.org/wiki/PT_TEC_Wallonie_BE_Import

I have to say I'm a bit pessimistic about getting it approved. I've been
lurking on the imports list for a while now and it's a bit depressing...

But we can always try, of course. Even though I realise in advance it will
get shot down on the silly dedicated import account rule alone.

In the mean time I'm doing test edits, to make sure the data conversion
went properly. It looks fine, as far as I'm concerned. Some abbreviations
don't get expanded properly yet (notably ones with a space after LE). I do
those by hand. Whoever wants to participate in adding these stops must
realise it not simply a matter of dragging them to their proper location,
but also the names need to be checked for consistency.

The zones and the calculated route_refs should be correct by now. The
village names are mostly properly converted and accents are put back where
they belong. Notify me if you find errors.

I'm always prepared to do a Google hangout in French, English or even Dutch
(for those who'd want to practice) to explain how I set up JOSM to make the
whole process more efficient. Additional buttons on the task bar for
presets and searches. dedicated MAPCSS style, which highlights the stops
and routes you are working on and something which creates display names
from distinct tags, so the routes get sorted in a better way in the
relations list.

Cheers,

Polyglot


2014-06-17 15:18 GMT+02:00 Ben Abelshausen :

> Hi,
>
> "Survey" does mean explicitly that there was an actual survey (meaning,
> going to each and every bus station to check if it is there!):
>
> http://wiki.openstreetmap.org/wiki/Survey#How_to_use
>
> Also make sure to check the import guidelines before importing anything:
>
> http://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Ben Abelshausen]

On Tue, Jun 17, 2014 at 3:16 PM, Marc Gemis  wrote:

> the source should a) contain some reference to TEC, b) any aerial image
> you have used (probably Bing).
>

Exactly!
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Ben Abelshausen]

Hi,

"Survey" does mean explicitly that there was an actual survey (meaning,
going to each and every bus station to check if it is there!):

http://wiki.openstreetmap.org/wiki/Survey#How_to_use

Also make sure to check the import guidelines before importing anything:

http://wiki.openstreetmap.org/wiki/Import/Guidelines

Met vriendelijke groeten,
Best regards,

Ben Abelshausen
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Marc Gemis]

>From http://wiki.openstreetmap.org/wiki/Map_Features#Annotation

source = survey Track from GPS unit (usually GPX fomat) or other physical
survey; suggested addition - survey:date
=-MM-DD

so IMHO checking the position on aerial images is not included
the source should a) contain some reference to TEC, b) any aerial image you
have used (probably Bing).

regards

m


On Tue, Jun 17, 2014 at 2:55 PM, André Pirard 
wrote:

>  On 2014-06-17 09:21, Marc Gemis wrote :
>
>
> On Mon, Jun 16, 2014 at 11:13 PM, André Pirard 
> wrote:
>
>> 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, but this is not a survey, this is an import.  IMHO, you can
> only use survey when you go out and check the exact position of the bus
> stop. A survey is not transforming data from one database format into
> another. So please do not use source=survey.
>
>  Survey is not just going out and check the bus position but ITHO
>
>  verb  (used with object)
> 2. to view in detail, especially to inspect, examine, or appraise formally
> or officially in order to ascertain condition, value, etc.
>
> that is, ascertaining, making sure that all data associated with the bus
> stop is correct.
>
> Importing the TEC data is the reason for adding/updating *TEC 2014-04*
> (allowing to check that the import was done).
> As the user applying this import is also requested (see instructions) to
> adjust the location of the bus stop (not by going out but simply with Bing
> etc.), all the data will be "ascertained" after doing that (unless other
> data is to be verified) and then the user can add *survey 2014-04* or
> later.
>
> *survey 2014-04* is not an indication of the import but is/should be in
> the imported data as a facility for the user to just copy it instead of
> having to "type" it for each bus stop. He may keep it, change it or delete
> it but you should not tell him not to use it.
>
> So please *do* use source=survey during the import, but (*obviously*)
> *only* after ascertaining all the data.
> It indicates that you have adjusted the location etc...  and that it must
> not be done 10 times.
>
>   André.
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-17 09:21, Marc Gemis wrote :
>
> On Mon, Jun 16, 2014 at 11:13 PM, André Pirard
> mailto:a.pirard.pa...@gmail.com>> wrote:
>
> 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, but this is not a survey, this is an import.  IMHO, you can
> only use survey when you go out and check the exact position of the
> bus stop. A survey is not transforming data from one database format
> into another. So please do not use source=survey.
>
Survey is not just going out and check the bus position but ITHO
> verb  (used with object)
>
> 2.to view in detail, especially to inspect, examine, or appraise
> formally or officially in order to ascertain condition, value, etc.
that is, ascertaining, making sure that all data associated with the bus
stop is correct.

Importing the TEC data is the reason for adding/updating *TEC 2014-04*
(allowing to check that the import was done).
As the user applying this import is also requested (see instructions) to
adjust the location of the bus stop (not by going out but simply with
Bing etc.), all the data will be "ascertained" after doing that (unless
other data is to be verified) and then the user can add *survey 2014-04*
or later.

*survey 2014-04* is not an indication of the import but is/should be in
the imported data as a facility for the user to just copy it instead of
having to "type" it for each bus stop. He may keep it, change it or
delete it but you should not tell him not to use it.

So please *do* use source=survey during the import, but (*obviously*)
*only* after ascertaining all the data.
It indicates that you have adjusted the location etc...  and that it
must not be done 10 times.

André.


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-17 00:07, Jo wrote :
> Answers inline.
>
>
> 2014-06-16 23:13 GMT+02:00 André Pirard  >:
>
> 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__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 -mm equals TEC -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 -mm and TEC -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.
Loo

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Marc Gemis]

On Mon, Jun 16, 2014 at 11:13 PM, André Pirard 
wrote:

> 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, but this is not a survey, this is an import.  IMHO, you can only
use survey when you go out and check the exact position of the bus stop. A
survey is not transforming data from one database format into another. So
please do not use source=survey.

regards

m
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

Answers inline.


2014-06-16 23:13 GMT+02:00 André Pirard :

>  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!

>
> 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.

>
> 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. 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.



>
> 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?

>
> 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.

> 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.


> 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.


> 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* .
>



>
>   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 that's not an URL and that is not clickable here
>   although we agreed using
> an URL (*network*=http://tec-wl.be   which is clickable here
> )  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.


>
>
> 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.

>
>
>  What we still need to discuss:
>
> The topics me

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

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!
A few remarks.

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.

Whatever I try, I see accent-less uppercased place names in your file.

I thought that you had found the line numbers, but I don't see them.

My file was displaying the lines (without number). Yours not.  Here is
an additional layer to display them.

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.
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.
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* .
> 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 that's not an URL and that is not clickable
here   although we agreed
using an URL (*network*=http://tec-wl.be   which is clickable here
)  then please add
website=http://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.

> 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."?

Cheers,

André.


>
> Polyglot
>
>
> 2014-06-16 1:38 GMT+02:00 André Pirard  >:
>
> Hi,
>
> I'm conducting an offline TEC conversation business with Jo and
> I'm impressed.
> You will soon be able to confidently buy TEC tickets and use the
> OSM transport map ;-)
>
> I have just two tag remarks.
>
> For the third time (Julien), if we want to use URLs, we'd better
> use URLs.
> network=tec-wl.be  is not an URL as you can see
> by not being able to click on it here
> .
> network=http://tec-wl.be is one as you can see by being able to
> click on it here .
>
> I recommend adding   *source=survey 2014-06  TEC 2014-04*
> Much like Key:source
>  indicates and I am
> presently proposing to amend slightly as shown below.
>
> The bulk import scenario was clearly written with in mind the idea
> to maintain a remaining-to do TEC file.
>
> Suppose an *.osm file is built from an imported source.  The map
> contributors are requested to move/update  the map elements to
> osm.org  after verifications such as coordinates. 
> If the *.osm map elements contain a survey value such as
> source=survey , then a program can find out by
> checking for an equal or later survey date what map elements have
> been moved/up

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

Hi,

The conversion is done. Municipality names are converted to lower case,
restoring the accents. Route_ref is calculated.

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.

As for the operator, I prefer to use simply TEC.

The OSM file with all the stops in Wallonia can be found here:
https://dl.dropboxusercontent.com/u/42418402/TEC.osm.zip

What we still need to discuss:

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'm not adding source on the objects anymore. Instead I add source tags on
the changeset as a whole.

Polyglot


2014-06-16 1:38 GMT+02:00 André Pirard :

>  Hi,
>
> I'm conducting an offline TEC conversation business with Jo and I'm
> impressed.
> You will soon be able to confidently buy TEC tickets and use the OSM
> transport map ;-)
>
> I have just two tag remarks.
>
> For the third time (Julien), if we want to use URLs, we'd better use URLs.
> network=tec-wl.be is not an URL as you can see by not being able to click
> on it here .
> network=http://tec-wl.be is one as you can see by being able to click on
> it here .
>
> I recommend adding   *source=survey 2014-06  TEC 2014-04*
> Much like Key:source 
> indicates and I am presently proposing to amend slightly as shown below.
>
> The bulk import scenario was clearly written with in mind the idea to
> maintain a remaining-to do TEC file.
>
> Suppose an *.osm file is built from an imported source.  The map
> contributors are requested to move/update  the map elements to osm.org
> after verifications such as coordinates.  If the *.osm map elements contain
> a survey value such as source=survey , then a program can find
> out by checking for an equal or later survey date what map elements have
> been moved/updated to osm.org and hence build a remaining.osm file
> containing what remains to be done.  A FIXME can be added at import time to
> already existing osm.org elements to warn about the ongoing import.
>
> Cheers,
>
>   André.
>
> Following this discussion here is a proposed clarification to Key:source
> .
> The goal is to define the word, make date mandatory, use ISO format,
> define per source tag meaning.
> Is there any objection or suggestion for changes?
>
> *survey* -mm[-dd] (with one blank and an *ISO* 8601
> 
> format date) can be used within the data of any source.KEY=* or source=*
> tag to indicate that, on that date, the source(s) of KEY were the most
> recent and the data was verified to be correct for that KEY. In source=*,
> survey means the same for all possible (required) keys (even those absent
> by default), but it can be overridden by survey in some source.KEY tags.
> survey helps to avoid making already done verifications, especially because
> a source publication date is not a verification date. survey can contain
> the date of dateless sources like visual or knowledge. It can help humanly
> assisted bulk imports. Please update the survey date of what you verify (a
> substantial time later), even if you don't add survey dates yourself.
>
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

Hi,

I'm conducting an offline TEC conversation business with Jo and I'm
impressed.
You will soon be able to confidently buy TEC tickets and use the OSM
transport map ;-)

I have just two tag remarks.

For the third time (Julien), if we want to use URLs, we'd better use URLs.
network=tec-wl.be is not an URL as you can see by not being able to
click on it here .
network=http://tec-wl.be is one as you can see by being able to click on
it here .

I recommend adding   *source=survey 2014-06  TEC 2014-04*
Much like Key:source 
indicates and I am presently proposing to amend slightly as shown below.

The bulk import scenario was clearly written with in mind the idea to
maintain a remaining-to do TEC file.

Suppose an *.osm file is built from an imported source.  The map
contributors are requested to move/update  the map elements to osm.org
after verifications such as coordinates.  If the *.osm map elements
contain a survey value such as source=survey , then a
program can find out by checking for an equal or later survey date what
map elements have been moved/updated to osm.org and hence build a
remaining.osm file containing what remains to be done.  A FIXME can be
added at import time to already existing osm.org elements to warn about
the ongoing import.

Cheers,

André.


> Following this discussion here is a proposed clarification to
> Key:source .
> The goal is to define the word, make date mandatory, use ISO format,
> define per source tag meaning.
> Is there any objection or suggestion for changes?
>
> *survey* -mm[-dd] (with one blank and an /ISO/ 8601
> 
> format date) can be used within the data of any source.KEY=* or
> source=* tag to indicate that, on that date, the source(s) of KEY were
> the most recent and the data was verified to be correct for that KEY.
> In source=*,  survey means the same for all possible (required) keys
> (even those absent by default), but it can be overridden by survey in
> some source.KEY tags. survey helps to avoid making already done
> verifications, especially because a source publication date is not a
> verification date. survey can contain the date of dateless sources
> like visual or knowledge. It can help humanly assisted bulk imports.
> Please update the survey date of what you verify (a substantial time
> later), even if you don't add survey dates yourself.

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-06-13 22:51, Jo wrote :
>
> Hi Andre,
>
> I'm almost done converting the village names to proper capitalisation,
> including accents. I also have a system set up to calculate route_ref.
> It's slower than I would like, but it works. (Reading the data into
> postGIS that is). Most of the work involved is stuff I had already
> done for the data of De Lijn. The data from TEC comes in a different
> format and I'm looking for a more efficient way to process it.
> Inserting line by line is not the way to go.
>
> I couldn't find your file, so I had to start from scratch.
>
I explained the reason why. I did not want taggers to use it and I asked
questions about the TEC problems to be discussed among involved persons
who would have had access to the file. As I was scolded before for
repeating problem reports, I did not ask a third time.
>
> Just a few more days and I'll release it.
>
> On Jun 13, 2014 10:37 PM, "André Pirard"  > wrote:
>
> Hi,
>
> I announced that I had made an OSM file from which it is very easy
> to copy with JOSM (Edit>Merge Selection) TEC bus stops to the OSM
> map.  I said that there were problems to discuss, principally
>
>   * that the data contains no bus line numbers
>   * that municipality names are in uppercase and with spelling
> errors (no accents)
>
> Nobody replied.
> So that I finally put this file aside so that nobody would start
> tagging incomplete data.
>
> Julien published
> 
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources/TEC
> I discovered my name in it, saying that I made an OSM file. Just that.
> As Julien says that he does not find interesting to hear problems
> reports repeated, I continued waiting.
>
> Then Jo got in contact with me and told me that he had made the
> same file as mine, but without lines.
> Then I found that in the above page, my name had been replaced
> with Polyglot without warning.
>
> Clearly, TEC is no longer my job.
> It is now Jo's job and I was glad to stop waiting.
>
> Jo wrote "I'm planning to convert the village names to normal
> capitalisation".
> Uppercasing is easy, but not correcting the spelling mistakes.
> I can try to do that. Just ask
>
> André.
>
>
> PS: I reported to SPW that the Géocatalogue
> 
> 
> (listing TEC's data) is perfectly empty; they forwarded the info.
> It happens to those who selected another language than French (in
> hope to see it round the corner).
>

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Jo]

Hi Andre,

I'm almost done converting the village names to proper capitalisation,
including accents. I also have a system set up to calculate route_ref. It's
slower than I would like, but it works. (Reading the data into postGIS that
is). Most of the work involved is stuff I had already done for the data of
De Lijn. The data from TEC comes in a different format and I'm looking for
a more efficient way to process it. Inserting line by line is not the way
to go.

I couldn't find your file, so I had to start from scratch.

Just a few more days and I'll release it.
On Jun 13, 2014 10:37 PM, "André Pirard"  wrote:

>  Hi,
>
> I announced that I had made an OSM file from which it is very easy to copy
> with JOSM (Edit>Merge Selection) TEC bus stops to the OSM map.  I said that
> there were problems to discuss, principally
>
>- that the data contains no bus line numbers
>- that municipality names are in uppercase and with spelling errors
>(no accents)
>
> Nobody replied.
> So that I finally put this file aside so that nobody would start tagging
> incomplete data.
>
> Julien published
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources/TEC
> I discovered my name in it, saying that I made an OSM file. Just that.
> As Julien says that he does not find interesting to hear problems reports
> repeated, I continued waiting.
>
> Then Jo got in contact with me and told me that he had made the same file
> as mine, but without lines.
> Then I found that in the above page, my name had been replaced with
> Polyglot without warning.
>
> Clearly, TEC is no longer my job.
> It is now Jo's job and I was glad to stop waiting.
>
> Jo wrote "I'm planning to convert the village names to normal
> capitalisation".
> Uppercasing is easy, but not correcting the spelling mistakes.
> I can try to do that. Just ask
>   André.
> PS: I reported to SPW that the Géocatalogue
> 
> (listing TEC's data) is perfectly empty; they forwarded the info.
> It happens to those who selected another language than French (in hope to
> see it round the corner).
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

  
  
Hi,

I announced that I had made an OSM file from which it is very easy
to copy with JOSM (Edit>Merge Selection) TEC bus stops to the OSM
map.  I said that there were problems to discuss, principally

  that the data contains no bus line numbers
  that municipality names are in uppercase and with spelling
errors (no accents)

Nobody replied.
  So that I finally put this file aside so that nobody would start
  tagging incomplete data.
 Julien published https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources/TEC
  I discovered my name in it, saying that I made an OSM file. Just
  that.
  As Julien says that he does not find interesting to hear problems
  reports repeated, I continued waiting.

Then Jo got in contact with me and told me that he had made the
  same file as mine, but without lines.
  Then I found that in the above page, my name had been replaced
  with Polyglot without warning.
 Clearly, TEC is no longer my job.
  It is now Jo's job and I was glad to stop waiting.

Jo wrote "I'm planning to convert the village names to normal
  capitalisation".
  Uppercasing is easy, but not correcting the spelling mistakes.
  I can try to do that. Just ask

  

  André.

  


PS: I reported to SPW that the Géocatalogue
(listing TEC's data) is perfectly empty; they forwarded the info.
It happens to those who selected another language than French (in
hope to see it round the corner).

  


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Julien Fastré]

Le 13/05/14 18:18, André Pirard a écrit :
> On 2014-05-13 16:57, Julien Fastré wrote :
>> We do agree with Champs Libres to install a WMS service with TEC
>> information (bus lines & stops). I had a problem to do that: we do
>> have reached our quota of IPv4 addresses on our servers and we would
>> do it with IPv6-only (tunnels IPv4->Ipv6 with sixxs or something else
>> should work and assure the connectivity).
> You can configure a host as a NAT router.  Assuming it's on host
> a.b.c.b (Internet address) and 192.168.0.0 is a local LAN,
> it would translate a.b.c.b:8080 -> 192.168.0.X:80 to access http port
> 80 of host X through port 8080 of the former.
Regarding our current installation, we had to reject this possibility
because this should not meet our requirements... More details in private
if you need this.

Thanks!
Julien

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

On 2014-05-13 16:57, Julien Fastré wrote :
> We do agree with Champs Libres to install a WMS service with TEC
> information (bus lines & stops). I had a problem to do that: we do
> have reached our quota of IPv4 addresses on our servers and we would
> do it with IPv6-only (tunnels IPv4->Ipv6 with sixxs or something else
> should work and assure the connectivity).
You can configure a host as a NAT router.  Assuming it's on host a.b.c.b
(Internet address) and 192.168.0.0 is a local LAN,
it would translate a.b.c.b:8080 -> 192.168.0.X:80 to access http port 80
of host X through port 8080 of the former.

Cheers,

André.



___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[André Pirard]

  
  
On 2014-04-25 08:26, Julien Fastré
  wrote :


  Hi !

Good news ! (Alleluia :-) )

The TEC is publishing now data under Open Data Licence !

On geoportail.wallonie.be, the data "Poteaux d'arrêts" (bus stop) and
"ligne de bus" (bus lines) are now under CC BY-SA 4.0 international
Licence :

http://geoportail.wallonie.be/geocatalogue?mdUUID=47676af7-aab3-4d2e-9c9c-cd86e7ad7241
http://geoportail.wallonie.be/geocatalogue?mdUUID=a5dc5bc7-3c37-4783-9c41-27ce2f83f3ae

The schedules are also available here :
http://opendata.awt.be/organization/groupe-tec (in a "Belgian format"...
glups... I still haven't opened it yet).

We are now allowed to import those data's in OSM.


Thanks Julien.
I'd gladly add this to my list of JOSM imagery sites but I see no
WMS configuration.
Is there a JOSM configuration?

If I try to look at the Arcgis configuration you mention
http://geodata.tec-wl.be/arcgis/rest/services/Poteaux/MapServer
 http://geodata.tec-wl.be/arcgis/rest/services/Lignes/MapServer

I get a 403 error.
How can it be used?

  Please, do not batch import ! 
  I saw in the previous version a lot of
  mistakes, comparing data to Bing! Imagery and also to Walloon's
  orthophotos. We may be more accurate than the original data :-)
What about importing the data to a TEC.osm file, splitting this file
into pieces to distribute to volunteers that would use JOSM to
overlay them on top of OSM and other maps, rectify them subpiece by
subpieces and move them to the OSM layer to update? I see references
  to OSM import tasking managers.

I'm glad to learn that the Walloon othophotos can be used to check,
understand and put right other maps.
I never fully understood the only phrase of their
  terms that seems to apply to us.
What does "ligne graphique" mean?
Can a SPW map be used to rectify another SPW map? ;-)

Beware of Bing! !!!  It has an offset error at high zoom in many
places responsible for many OSM imprecisions.
The recently mentioned Mapbox seems to have the same images as Bing!
but with a different offset.
I didn't check (yet) if it exhibits the same errors as Bing!
At
  Champs Libres, we are planning to provide an online "comparator"
  from
  TEC data to OSM data, using the old and new public transport
  schema.
  This will allow to see where are missing bus stops, where they are
  mispelled, etc. We will do it during May.

If the SPW keeps not making a WMS server, what about making a Champs
Libres proxy serving WMS?
This would allow doing what you say together with OSM updates while
staying in the same JOSM window.

Cheers,



  

  André.

  


  


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] TEC & Open Data: let's start !

[Martin]

Hi,

Good news indeed.
I did a quick search on the format. It uses the BLTAC format (Belgium
Local Transport Automatic Connexion).If you open data you will get a
bunch of text files not very easy to understand.

Hopefully, they gave also the documentation of the BLTAC format[1] and I
found a csv version (a bit more human friendly) here[2] with at least
the coordinates of the bus stops.

Martin

[1] http://opendata.awt.be/dataset/documentation-des-donnees-horaires-tec**
[2] http://datahub.io/fr/dataset/tec

On 25/04/14 08:26, Julien Fastré wrote:
> Hi !
>
> Good news ! (Alleluia :-) )
>
> The TEC is publishing now data under Open Data Licence !
>
> On geoportail.wallonie.be, the data "Poteaux d'arrêts" (bus stop) and
> "ligne de bus" (bus lines) are now under CC BY-SA 4.0 international
> Licence :
>
> http://geoportail.wallonie.be/geocatalogue?mdUUID=47676af7-aab3-4d2e-9c9c-cd86e7ad7241
> http://geoportail.wallonie.be/geocatalogue?mdUUID=a5dc5bc7-3c37-4783-9c41-27ce2f83f3ae
>
> The schedules are also available here :
> http://opendata.awt.be/organization/groupe-tec (in a "Belgian format"...
> glups... I still haven't opened it yet).
>
> We are now allowed to import those data's in OSM.
>
> Please, do not batch import ! I saw in the previous version a lot of
> mistakes, comparing data to Bing! Imagery and also to Walloon's
> orthophotos. We may be more accurate than the original data :-)
>
> At Champs Libres, we are planning to provide an online "comparator" from
> TEC data to OSM data, using the old and new public transport schema.
> This will allow to see where are missing bus stops, where they are
> mispelled, etc. We will do it during May.
>
> Julien
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] TEC & Open Data: let's start !

[Julien Fastré]

Hi !

Good news ! (Alleluia :-) )

The TEC is publishing now data under Open Data Licence !

On geoportail.wallonie.be, the data "Poteaux d'arrêts" (bus stop) and
"ligne de bus" (bus lines) are now under CC BY-SA 4.0 international
Licence :

http://geoportail.wallonie.be/geocatalogue?mdUUID=47676af7-aab3-4d2e-9c9c-cd86e7ad7241
http://geoportail.wallonie.be/geocatalogue?mdUUID=a5dc5bc7-3c37-4783-9c41-27ce2f83f3ae

The schedules are also available here :
http://opendata.awt.be/organization/groupe-tec (in a "Belgian format"...
glups... I still haven't opened it yet).

We are now allowed to import those data's in OSM.

Please, do not batch import ! I saw in the previous version a lot of
mistakes, comparing data to Bing! Imagery and also to Walloon's
orthophotos. We may be more accurate than the original data :-)

At Champs Libres, we are planning to provide an online "comparator" from
TEC data to OSM data, using the old and new public transport schema.
This will allow to see where are missing bus stops, where they are
mispelled, etc. We will do it during May.

Julien

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be