Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Andre Engels
On Sat, Nov 13, 2010 at 8:08 PM, Ben Laenen  wrote:

> I depends on your interpretation of the database rights in this particular
> case. It speaks about "substantial" subsets. It also says that the database
> right only matters if a considerable effort has been made to create the
> database. It has been argued that the timetables are a "side-effect" of what
> De Lijn is doing: driving buses and trams around, and therefore a database
> with their timetables didn't constitute a substantial effort to build. I think
> that in the Netherlands this was even brought to court, but I forgot the
> details on how it all went exactly.

I think you're now talking about a case (LJN AF5100, NJ 2003/505)
about the broadcast data of the Dutch public television (which
programs are being broadcasted when). Because this is data that must
be created and kept by the broadcaster anyway, the cost of getting the
data is not an investment in the database, but only the cost of
preparing the data so it can be put into the database. As the judge
writes:

Daarbij komt dat de Omroepen, waarvan de primaire taak is om landelijk
radio‑ en televisieuitzendingen te verzorgen, deze taak niet kunnen
vervullen zonder programmagegevens te verzamelen en programmalijsten
op te stellen, waarbij, nu het tegendeel niet aannemelijk is geworden,
moet worden aangenomen dat met het enkele opstellen van
programmalijsten geen (afzonderlijke) substantiële investeringen in
tijd, geld of anderszins zijn gemoeid.
Hiervoor vindt het hof mede steun in het standpunt van de minister van
Justitie, waaruit valt af te leiden dat een substantiële investering
kan ontbreken als televisieprogramma-gegevens niet meer zijn dan een
spin-off van het programmeren van de zender (Parlementaire
geschiedenis Databankenwet, Nota naar aanleiding van het Verslag
(Tweede Kamer)).

-- 
André Engels, andreeng...@gmail.com

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Ben Laenen
Let's first put an IANAL disclaimer here, but here goes:

Gerard Vanderveken wrote:
> There is always a copyright, on data, and in fact on everything written.
> Depending on the source and its associated license, we are allowed to
> use it in OSM.

There is no copyright on a fact. It's for example a fact that a bus line with 
number X follows certain streets, and everyone can use that information how he 
likes.

(It's for this reason btw some people don't like the CC license for OSM: it's 
a set of facts and hence not part of copyright law, the only thing that CC 
licenses rely on -- opinions vary though.)

As said in my previous mail: the problem with importing data sets is that (in 
Europe) the database rights come into play. You cannot copy a substantial 
subset from a database and reproduce it.

(Again, with the license issue in OSM: ODbL has clauses for database right)


> Strictly seen the numbers and other texts on the bus, sign poles and
> shedules are written by De Lijn and they do also have the copyright to it.
> (Must check it once, but I assume it may explicitly be marked on their
> shedules with the copyright symbol ©, altough this marking is not needed
> to own the copyright. )
> 
> They are intended to inform the public, but this does not mean that you
> have the right to duplicate for instance the complete shedules and make
> them public available.

I depends on your interpretation of the database rights in this particular 
case. It speaks about "substantial" subsets. It also says that the database 
right only matters if a considerable effort has been made to create the 
database. It has been argued that the timetables are a "side-effect" of what 
De Lijn is doing: driving buses and trams around, and therefore a database 
with their timetables didn't constitute a substantial effort to build. I think 
that in the Netherlands this was even brought to court, but I forgot the 
details on how it all went exactly.

But let's be clear: copyright has nothing to do with this here. Bus routes are 
not and cannot be copyrighted.


> (I think you will run into big trouble by making similar data as what is
> specified in their 'dienstroosters' available in a book or on a website
> without having the proper authorisation from De Lijn.

Fill this in into the concept of database right: substantial subset of their 
data set: not allowed.

Copying the timetables of a bus halt and putting it on the website of the shop 
you have for example: that's not a problem. You cannot say that the timetable 
of one bus halt is a substantial subset of the entire timetable database.


> And in the same way, it is not because a movie is showed to the public
> that you may duplicate it.

But movies are copyrighted.


> Without some additional legislation to have automatic public domain for
> all data from public bodies, it makes no difference if the copyright is
> owned by a public or private company.)

Wet op openbaarheid van bestuur. But then we're heading into another 
adventure. In principle the data that our governments produce and use should 
be open to anyone (not necessarily free of copyright though for some data). 
But you can pretty much do anything with for example the "notulen" of your 
city council (you cannot just sell them as is, but you can use the information 
in them commercially).


> Some things like the line numbers and names of the routes could be by
> their nature considered as common knowledge and thus public domain, but
> being public domain is AFAIK not the case for the 4 digit number and its
> source for line and stop numbers.
> They should therefore not to be used in OSM

If you do know that that's their internal number, there's no issue. They're a 
fact and as said above: no copyright exists on a fact.

 
> (Streetnames (which are the core of OSM) are different in that respect
> as they are given/named by the public and exists for a very long time.)

It's a bit different. It's true that some street names are very old, but in 
fact your municipality will have a street name list (government data, free to 
use if you can get it -- and you must get it if you ask). When a new street is 
built that needs a new name, it'll be voted on by your municipality council 
and added to that list. You have to check the "notulen" of your city once, so 
you'll learn how this process works.

In any way, the fact that a certain street has a certain name again has no 
copyright. That we can use the street name list (which is somewhat like a 
database), is because it's official data from our government, and then because 
of the wet op openbaarheid van bestuur, you're allowed to use it.

Ben

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Jo
I agree with you, ofc. The reason for using child relations was because so
many bus routes share the same roads. I'm starting to think, maybe another
level of abstraction is needed. A totally separate set of relations.

What we have now:

1 route relation for each direction (even though, even that is being
disputed), containing all segments and all stops where this bus stops
1 relation grouping these sets of route relations. Maybe this one should get
another name. PTLine (public transportation line)

In order to be able to maintain all this data, maybe we could have the child
relations as 'routepart' and 'protoroute' relations to combine them. Then we
(I) could write some software to convert them to the actual route relations
that the routers/map drawing SW can work with.

Then if a change is needed, the editor adapts the protoroute and/or the
segments and runs the conversion tool.

Jo

2010/11/13 Renaud MICHEL 
>

> Le samedi 13 novembre 2010 à 15:37, Jo a écrit :
> > Now I'll go and eradicate the child relations... after that, not sure if
> > I'll touch any public transport data anymore, apart from a bus stop here
> > or there.
>
> Why?
> It is much more easier to have the common part of alternative bus routes in
> a single relation shared by all the alternatives.
>
> In Liège I have mapped bus route 10, there are 3 variation of this bus
> route:
> 10 Fléron http://www.openstreetmap.org/browse/relation/1148168
> 10 Mangée http://www.openstreetmap.org/browse/relation/1148170
> 10 Romsée http://www.openstreetmap.org/browse/relation/1148169
> Up to Fléron, those three are identical, so that common part is in relation
> http://www.openstreetmap.org/browse/relation/1148167
> which is shared by the three, further, 10 Magnée and Romsée share a small
> part which I have put in relation
> http://www.openstreetmap.org/browse/relation/1148166
>
> It is much easier to have it that way, if a bus stop change in the common
> part it must only be changed in one relation (and maybe others if the same
> stop is part of different routes, like 38b).
>
> I intend to do the same for other bus routes that I map (I already have a
> work in progress for 33 which also have alternatives (33 Vaux, 33 Trooz).
>
> --
> Renaud Michel
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Ivo De Broeck
2010/11/13 Gerard Vanderveken 

>  There is always a copyright, on data, and in fact on everything written.
> Depending on the source and its associated license, we are allowed to use
> it in OSM.
>
> Strictly seen the numbers and other texts on the bus, sign poles and
> shedules are written by De Lijn and they do also have the copyright to it.
> (Must check it once, but I assume it may explicitly be marked on their
> shedules with the copyright symbol ©, altough this marking is not needed to
> own the copyright. )
>
> They are intended to inform the public, but this does not mean that you
> have the right to duplicate for instance the complete shedules and make them
> public available.
> (I think you will run into big trouble by making similar data as what is
> specified in their 'dienstroosters' available in a book or on a website
> without having the proper authorisation from De Lijn.
> And in the same way, it is not because a movie is showed to the public that
> you may duplicate it.
> Without some additional legislation to have automatic public domain for all
> data from public bodies, it makes no difference if the copyright is owned by
> a public or private company.)
>
> Some things like the line numbers and names of the routes could be by their
> nature considered as common knowledge and thus public domain, but being
> public domain is AFAIK not the case for the 4 digit number and its source
> for line and stop numbers.
> They should therefore not to be used in OSM
>
> (Streetnames (which are the core of OSM) are different in that respect as
> they are given/named by the public and exists for a very long time.)
>
>
>

Streetnames are NOT given by the public, its a official decision of
the municipality Council, some of them are brand new too.
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Gerard Vanderveken
People will see a gap in the route as showed on the map and try to 
complete it by adding the missing roads.


Ben Laenen wrote:


Ivo De Broeck wrote:
 


The main reason to not use child relations is because the maintenance is
difficult for other users.
   



I wonder when this myth will finally be gone. If you're not mapping bus routes 
yourself, you can be completely unaware of whether those bus routes belong to 
parents relations or not. You'll only see the routes themselves, and have to 
handle them like any other route relation if you're editing the ways.


Ben

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

 

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Gerard Vanderveken

There is always a copyright, on data, and in fact on everything written.
Depending on the source and its associated license, we are allowed to 
use it in OSM.


Strictly seen the numbers and other texts on the bus, sign poles and 
shedules are written by De Lijn and they do also have the copyright to it.
(Must check it once, but I assume it may explicitly be marked on their 
shedules with the copyright symbol ©, altough this marking is not needed 
to own the copyright. )


They are intended to inform the public, but this does not mean that you 
have the right to duplicate for instance the complete shedules and make 
them public available.
(I think you will run into big trouble by making similar data as what is 
specified in their 'dienstroosters' available in a book or on a website 
without having the proper authorisation from De Lijn.
And in the same way, it is not because a movie is showed to the public 
that you may duplicate it.
Without some additional legislation to have automatic public domain for 
all data from public bodies, it makes no difference if the copyright is 
owned by a public or private company.)


Some things like the line numbers and names of the routes could be by 
their nature considered as common knowledge and thus public domain, but 
being public domain is AFAIK not the case for the 4 digit number and its 
source for line and stop numbers.

They should therefore not to be used in OSM

(Streetnames (which are the core of OSM) are different in that respect 
as they are given/named by the public and exists for a very long time.)


Ben Laenen wrote:


Gerard Vanderveken wrote:
 


I tend to consider them as copyrighted material, and thus forbidden to
be used at all with OSM
   




There's no copyright on factual data. The reason why we cannot import the data 
from De Lijn is because of database rights (*).


Ben


(*) actually, some people argue that this data doesn't qualify to be under 
database right, but that's another discussion.


 

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Renaud MICHEL
Le samedi 13 novembre 2010 à 15:37, Jo a écrit :
> Now I'll go and eradicate the child relations... after that, not sure if
> I'll touch any public transport data anymore, apart from a bus stop here
> or there.

Why?
It is much more easier to have the common part of alternative bus routes in 
a single relation shared by all the alternatives.

In Liège I have mapped bus route 10, there are 3 variation of this bus 
route:
10 Fléron http://www.openstreetmap.org/browse/relation/1148168
10 Mangée http://www.openstreetmap.org/browse/relation/1148170
10 Romsée http://www.openstreetmap.org/browse/relation/1148169
Up to Fléron, those three are identical, so that common part is in relation
http://www.openstreetmap.org/browse/relation/1148167
which is shared by the three, further, 10 Magnée and Romsée share a small 
part which I have put in relation
http://www.openstreetmap.org/browse/relation/1148166

It is much easier to have it that way, if a bus stop change in the common 
part it must only be changed in one relation (and maybe others if the same 
stop is part of different routes, like 38b).

I intend to do the same for other bus routes that I map (I already have a 
work in progress for 33 which also have alternatives (33 Vaux, 33 Trooz).

-- 
Renaud Michel

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Jo
2010/11/13 Renaud MICHEL 
>

> Le samedi 13 novembre 2010 à 14:42, Gerard Vanderveken a écrit :
> > I tend to consider them as copyrighted material, and thus forbidden to
> > be used at all with OSM
>
> How can a number be copyrighted?
>
> Indeed. But anyway, after this much adversity to something that had seemed
like a good idea to me, in order to distinguish a 410 between Brussels and
Leuven and another one in Antwerp, let alone all the lines with single digit
numbers, I gave up. All lines I touched have the sensible numbering scheme
removed.

Now I'll go and eradicate the child relations... after that, not sure if
I'll touch any public transport data anymore, apart from a bus stop here or
there.

I remain convinced that the route per direction of a bus line is a good idea
and I'm sure if you ask your German friend, he'll agree. That's where the
idea came from, anyway.

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Renaud MICHEL
Le samedi 13 novembre 2010 à 14:42, Gerard Vanderveken a écrit :
> I tend to consider them as copyrighted material, and thus forbidden to 
> be used at all with OSM

How can a number be copyrighted?

-- 
Renaud Michel

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Ben Laenen
Gerard Vanderveken wrote:
> I tend to consider them as copyrighted material, and thus forbidden to
> be used at all with OSM


There's no copyright on factual data. The reason why we cannot import the data 
from De Lijn is because of database rights (*).

Ben


(*) actually, some people argue that this data doesn't qualify to be under 
database right, but that's another discussion.

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Gerard Vanderveken
I tend to consider them as copyrighted material, and thus forbidden to 
be used at all with OSM


Ben Laenen wrote:


Jo wrote:
 


3308. Four digits seems to be enough to uniquely identify all routes in
Flanders. If one searches on ref, one can find all buses that have '8' on
them. If one searches on To= one can find all buses that are going to
Bertem.
   



Numbers that the general public are unaware of shouldn't be in the ref or name 
tags. You can create other tags for it, like internal_ref or admin_ref. It 
would just confuse people otherwise.


Ben

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

 

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Gerard Vanderveken



Jo wrote:

I tend to agree with you as far as creating child relations for the 
routes goes. It was an experiment of mine. There is no support for it 
in the editors, nor the renderers, so I'll probably let it go. It 
seems like a more maintainable way to do things, to me, but I'm 
standing alone in this. An other way of doing it, might be 
'proto-relations' and 'routeparts', which get converted to the route 
relations by a script.


Concerning those 4-digit numbers of the lines. They can be found on 
those displays which are meant for the drivers (only in the bigger 
terminals). By naming the routes De Lijn , all the bus routes of 
De Lijn get sorted together in the relations subwindow. You complain 
about people starting new routes, when a route already exists, well 
this was already happening. (395 is one that I found yesterday). 
Naming them in an unambiguous way and sorting them all together, will 
avoid people creating route relations more than once.


That is exactly my point.
These 4 digit numbers are not commonly available or destinated to the 
public and should therefore not to be used.
At a certain road, the routes are uniquely distinguished by their 1 or 3 
digit number as showed on the bus  and the stops.


Only the commonly knowed numbers should be used !



I don't agree concerning the route per direction of a bus line. This 
is the best way to unambiguously indicate where the buses are 
travelling. I just added line 179 between Etterbeek and Leuven (Fast 
bus that only runs on Fridays and Sundays between VUB and Hamont). The 
two directions of this line are almost completely separate (since it 
travels over Bvd. Général Jacques then E40, then the ring of Leuven). 
By creating a route per direction, one obtains a long sequence of 
consecutive segments. By combining the 2 directions, this is not possible.


If you make a route with a different forward and backward segment, it is 
inherent that you can not make one list where all street segments follow 
each other from begin to the end.
Most logical approach is to order the segments from beginning to the 
join in the forward sense.
Then list the backward segments from the split to the join and then 
continue with the rest of the route.


Such a combined list is suitable for routing, because a route consists 
of segments with no (=both) direction and depending on the sense, all 
forward or all backward segments.
If the routeplanner discards the unwanted forward or backward segments 
from such a list, they have an ordered list of all the ways in that 
route from beginning to end.


I'm not convinced that you need two relations for your example.
See eg De Lijn 630 Haasrode Brabanthal - Wijgmaal Remy (v100), where the 
route has a different path at  the ring.

http://www.openstreetmap.org/?lat=50.88293&lon=4.71149&zoom=16&layers=M&relation=955963
It looks perfect to me and I don't see what is wrong with that (apart 
for some missing crossing at the Diestsesteenweg).


Making two relations will also confuse people as to where additions or 
modifications should be made.
Also the reversed naming may add to this confusion eg Leuven - Wavre <=> 
Wavre - Leuven (there is no such line, only the route followed backward).
If you ask people for the name of the bus line that they use to travel 
from midway to either Leuven or Wavre, in both cases people say: I took 
the Leuven - Wavre to go to Leuven (or Wavre).

It will also be double work to maintain them.




We are not simply creating a graphical map, we have to think of being 
able to use this data for routing eventually. Even when today this is 
not possible yet.


Jo



2010/11/13 Gerard Vanderveken mailto:g...@ghia.eu>>

I think you are making it all too complicated.

For most bus routes only 1 relation is sufficient.
There is no reason for doubling all routes by default.

Also making relations members of other relations is a mistake.
The data of OSM is flat and not layered.
See also Members of a route:
http://wiki.openstreetmap.org/wiki/Relation:route#Members
These are only ways (routes) and stops (points).

Also the renderers do not take into account these child relations:

http://www.openstreetmap.org/?lat=50.8752&lon=4.6983&zoom=14&layers=M&relation=1269869


Even not the demo project for public transport routes..

http://3liz.fr/public/osmtransport/index.php?country=Belgium&location=Overijse


- drag map to Leuven - click + buslines - click null

Also when you request info of a street or stop, you see immediate
which
routes are passing  and you do not need to click all relations to
see if
they contain other routes.

We should only map the permanent location of a route.
Temporary deviations are not needed. If a traveler goes to the
st

Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Ben Laenen
Ivo De Broeck wrote:
> The main reason to not use child relations is because the maintenance is
> difficult for other users.

I wonder when this myth will finally be gone. If you're not mapping bus routes 
yourself, you can be completely unaware of whether those bus routes belong to 
parents relations or not. You'll only see the routes themselves, and have to 
handle them like any other route relation if you're editing the ways.

Ben

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Ben Laenen
Jo wrote:
> 3308. Four digits seems to be enough to uniquely identify all routes in
> Flanders. If one searches on ref, one can find all buses that have '8' on
> them. If one searches on To= one can find all buses that are going to
> Bertem.

Numbers that the general public are unaware of shouldn't be in the ref or name 
tags. You can create other tags for it, like internal_ref or admin_ref. It 
would just confuse people otherwise.

Ben

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Benoit Leseul
On Sat, Nov 13, 2010 at 08:43, Gerard Vanderveken  wrote:
> [...]
> Even not the demo project for public transport routes..
> http://3liz.fr/public/osmtransport/index.php?country=Belgium&location=Overijse
> - drag map to Leuven - click + buslines - click null

Indeed, I talked with the OSMTransport developer in October, and he
seemed quite worried by the complexity of some relations in Belgium.
Using too many levels of abstraction is hurting his project and makes
the current live rendering impractical.

If I remember correctly, his conclusion was that he stopped caring
about some unusual schemes, and it might well be the case here.

Sometimes, "less is more", or as we say in French, "le mieux est
l'ennemi du bien".

-- 
Benoit

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


Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Jo
2010/11/13 Ivo De Broeck 

> 2010/11/13 Jo 
>
>> I tend to agree with you as far as creating child relations for the routes
>> goes. It was an experiment of mine. There is no support for it in the
>> editors, nor the renderers, so I'll probably let it go. It seems like a more
>> maintainable way to do things, to me, but I'm standing alone in this. An
>> other way of doing it, might be 'proto-relations' and 'routeparts', which
>> get converted to the route relations by a script.
>>
>
> The main reason to not use child relations is because the maintenance is
> difficult for other users.
>

It's a complicated problem, there is no easy solution.

>
>> Concerning those 4-digit numbers of the lines. They can be found on those
>> displays which are meant for the drivers (only in the bigger terminals). By
>> naming the routes De Lijn , all the bus routes of De Lijn get sorted
>> together in the relations subwindow. You complain about people starting new
>> routes, when a route already exists, well this was already happening. (395
>> is one that I found yesterday). Naming them in an unambiguous way and
>> sorting them all together, will avoid people creating route relations more
>> than once.
>>
>
> A good idea to avoid double relations. But who will search for "De Lijn
> 33008" ? I suppose other people will search for "bus 8 Bertem".
>

3308. Four digits seems to be enough to uniquely identify all routes in
Flanders. If one searches on ref, one can find all buses that have '8' on
them. If one searches on To= one can find all buses that are going to
Bertem.

>
>> I don't agree concerning the route per direction of a bus line. This is
>> the best way to unambiguously indicate where the buses are travelling. I
>> just added line 179 between Etterbeek and Leuven (Fast bus that only runs on
>> Fridays and Sundays between VUB and Hamont). The two directions of this line
>> are almost completely separate (since it travels over Bvd. Général Jacques
>> then E40, then the ring of Leuven). By creating a route per direction, one
>> obtains a long sequence of consecutive segments. By combining the 2
>> directions, this is not possible.
>>
>> That is one good reason, but for me it is important that i can find "real
> information" at a bus-stop. That means that i can see if the bus at that
> bus-stop goes to Etterbeek OR to Leuven. So i am also convinced we need 2
> separate relations for this 2 reasons.
>
>
>
>> We are not simply creating a graphical map, we have to think of being able
>> to use this data for routing eventually. Even when today this is not
>> possible yet.
>>
>
> Even on a graphical map we need to have all bus-stops and the relations
> (directions).
>
>>
>> Jo
>>
>>
>>
>> 2010/11/13 Gerard Vanderveken 
>>
>> I think you are making it all too complicated.
>>>
>>> For most bus routes only 1 relation is sufficient.
>>> There is no reason for doubling all routes by default.
>>>
>>> Also making relations members of other relations is a mistake.
>>> The data of OSM is flat and not layered.
>>> See also Members of a route:
>>> http://wiki.openstreetmap.org/wiki/Relation:route#Members
>>> These are only ways (routes) and stops (points).
>>>
>>> Also the renderers do not take into account these child relations:
>>>
>>> http://www.openstreetmap.org/?lat=50.8752&lon=4.6983&zoom=14&layers=M&relation=1269869
>>> Even not the demo project for public transport routes..
>>>
>>> http://3liz.fr/public/osmtransport/index.php?country=Belgium&location=Overijse
>>> - drag map to Leuven - click + buslines - click null
>>>
>>> Also when you request info of a street or stop, you see immediate which
>>> routes are passing  and you do not need to click all relations to see if
>>> they contain other routes.
>>>
>>> We should only map the permanent location of a route.
>>> Temporary deviations are not needed. If a traveler goes to the stop, he
>>> will retrieve an info board of De Lijn saying that the halt is
>>> suspended/replaced.
>>>
>>> For alternatives and variations there is an alternative tag.
>>> For shorter routes, it is up to the traveler, to inform him on the times
>>> when the bus services the required stops.
>>>
>>> For the time being, there are no good possibilities to incorporate
>>> shedules etc in OSM.
>>> Making some preparations to facilitate this is futile, because this
>>> surpasses the normal mapping properties. Probably the needed data and/or
>>> its form will also be determined by the application that will make them
>>> available.
>>> You could for example starting by using the opening hours tag and thus
>>> indicating for a bus stop all the times when a bus passes.
>>> Then you envisage a lot of problems:  the stop can be serviced by
>>> several lines, there are normal days and school days, night bus, ...
>>> To have all this in one tag or several tags, makes always a big list of
>>> data, which will be to entered very punctual to be usable.
>>> And the question is of any application, will be able to make good 

Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Ivo De Broeck
2010/11/13 Jo 

> I tend to agree with you as far as creating child relations for the routes
> goes. It was an experiment of mine. There is no support for it in the
> editors, nor the renderers, so I'll probably let it go. It seems like a more
> maintainable way to do things, to me, but I'm standing alone in this. An
> other way of doing it, might be 'proto-relations' and 'routeparts', which
> get converted to the route relations by a script.
>

The main reason to not use child relations is because the maintenance is
difficult for other users.

>
> Concerning those 4-digit numbers of the lines. They can be found on those
> displays which are meant for the drivers (only in the bigger terminals). By
> naming the routes De Lijn , all the bus routes of De Lijn get sorted
> together in the relations subwindow. You complain about people starting new
> routes, when a route already exists, well this was already happening. (395
> is one that I found yesterday). Naming them in an unambiguous way and
> sorting them all together, will avoid people creating route relations more
> than once.
>

A good idea to avoid double relations. But who will search for "De Lijn
33008" ? I suppose other people will search for "bus 8 Bertem".

>
> I don't agree concerning the route per direction of a bus line. This is the
> best way to unambiguously indicate where the buses are travelling. I just
> added line 179 between Etterbeek and Leuven (Fast bus that only runs on
> Fridays and Sundays between VUB and Hamont). The two directions of this line
> are almost completely separate (since it travels over Bvd. Général Jacques
> then E40, then the ring of Leuven). By creating a route per direction, one
> obtains a long sequence of consecutive segments. By combining the 2
> directions, this is not possible.
>
> That is one good reason, but for me it is important that i can find "real
information" at a bus-stop. That means that i can see if the bus at that
bus-stop goes to Etterbeek OR to Leuven. So i am also convinced we need 2
separate relations for this 2 reasons.



> We are not simply creating a graphical map, we have to think of being able
> to use this data for routing eventually. Even when today this is not
> possible yet.
>

Even on a graphical map we need to have all bus-stops and the relations
(directions).

>
> Jo
>
>
>
> 2010/11/13 Gerard Vanderveken 
>
> I think you are making it all too complicated.
>>
>> For most bus routes only 1 relation is sufficient.
>> There is no reason for doubling all routes by default.
>>
>> Also making relations members of other relations is a mistake.
>> The data of OSM is flat and not layered.
>> See also Members of a route:
>> http://wiki.openstreetmap.org/wiki/Relation:route#Members
>> These are only ways (routes) and stops (points).
>>
>> Also the renderers do not take into account these child relations:
>>
>> http://www.openstreetmap.org/?lat=50.8752&lon=4.6983&zoom=14&layers=M&relation=1269869
>> Even not the demo project for public transport routes..
>>
>> http://3liz.fr/public/osmtransport/index.php?country=Belgium&location=Overijse
>> - drag map to Leuven - click + buslines - click null
>>
>> Also when you request info of a street or stop, you see immediate which
>> routes are passing  and you do not need to click all relations to see if
>> they contain other routes.
>>
>> We should only map the permanent location of a route.
>> Temporary deviations are not needed. If a traveler goes to the stop, he
>> will retrieve an info board of De Lijn saying that the halt is
>> suspended/replaced.
>>
>> For alternatives and variations there is an alternative tag.
>> For shorter routes, it is up to the traveler, to inform him on the times
>> when the bus services the required stops.
>>
>> For the time being, there are no good possibilities to incorporate
>> shedules etc in OSM.
>> Making some preparations to facilitate this is futile, because this
>> surpasses the normal mapping properties. Probably the needed data and/or
>> its form will also be determined by the application that will make them
>> available.
>> You could for example starting by using the opening hours tag and thus
>> indicating for a bus stop all the times when a bus passes.
>> Then you envisage a lot of problems:  the stop can be serviced by
>> several lines, there are normal days and school days, night bus, ...
>> To have all this in one tag or several tags, makes always a big list of
>> data, which will be to entered very punctual to be usable.
>> And the question is of any application, will be able to make good use of
>> it and not require another format.
>>
>> To support this manually is impossible. To import it, you need clearence.
>> To show it, you need applications.
>> None of them are for the moment envisaged, so a link to the webaddress
>> of the routes its dienstregeling will be at the time being the best to
>> offer eg:
>> http://reisinfo.delijn.be/dienstregelingen/
>> Also the amount of data is also substantial, whi

Re: [OSM-talk-be] Busroutes

2010-11-13 Thread Jo
I tend to agree with you as far as creating child relations for the routes
goes. It was an experiment of mine. There is no support for it in the
editors, nor the renderers, so I'll probably let it go. It seems like a more
maintainable way to do things, to me, but I'm standing alone in this. An
other way of doing it, might be 'proto-relations' and 'routeparts', which
get converted to the route relations by a script.

Concerning those 4-digit numbers of the lines. They can be found on those
displays which are meant for the drivers (only in the bigger terminals). By
naming the routes De Lijn , all the bus routes of De Lijn get sorted
together in the relations subwindow. You complain about people starting new
routes, when a route already exists, well this was already happening. (395
is one that I found yesterday). Naming them in an unambiguous way and
sorting them all together, will avoid people creating route relations more
than once.

I don't agree concerning the route per direction of a bus line. This is the
best way to unambiguously indicate where the buses are travelling. I just
added line 179 between Etterbeek and Leuven (Fast bus that only runs on
Fridays and Sundays between VUB and Hamont). The two directions of this line
are almost completely separate (since it travels over Bvd. Général Jacques
then E40, then the ring of Leuven). By creating a route per direction, one
obtains a long sequence of consecutive segments. By combining the 2
directions, this is not possible.

We are not simply creating a graphical map, we have to think of being able
to use this data for routing eventually. Even when today this is not
possible yet.

Jo



2010/11/13 Gerard Vanderveken 

> I think you are making it all too complicated.
>
> For most bus routes only 1 relation is sufficient.
> There is no reason for doubling all routes by default.
>
> Also making relations members of other relations is a mistake.
> The data of OSM is flat and not layered.
> See also Members of a route:
> http://wiki.openstreetmap.org/wiki/Relation:route#Members
> These are only ways (routes) and stops (points).
>
> Also the renderers do not take into account these child relations:
>
> http://www.openstreetmap.org/?lat=50.8752&lon=4.6983&zoom=14&layers=M&relation=1269869
> Even not the demo project for public transport routes..
>
> http://3liz.fr/public/osmtransport/index.php?country=Belgium&location=Overijse
> - drag map to Leuven - click + buslines - click null
>
> Also when you request info of a street or stop, you see immediate which
> routes are passing  and you do not need to click all relations to see if
> they contain other routes.
>
> We should only map the permanent location of a route.
> Temporary deviations are not needed. If a traveler goes to the stop, he
> will retrieve an info board of De Lijn saying that the halt is
> suspended/replaced.
>
> For alternatives and variations there is an alternative tag.
> For shorter routes, it is up to the traveler, to inform him on the times
> when the bus services the required stops.
>
> For the time being, there are no good possibilities to incorporate shedules
> etc in OSM.
> Making some preparations to facilitate this is futile, because this
> surpasses the normal mapping properties. Probably the needed data and/or
> its form will also be determined by the application that will make them
> available.
> You could for example starting by using the opening hours tag and thus
> indicating for a bus stop all the times when a bus passes.
> Then you envisage a lot of problems:  the stop can be serviced by
> several lines, there are normal days and school days, night bus, ...
> To have all this in one tag or several tags, makes always a big list of
> data, which will be to entered very punctual to be usable.
> And the question is of any application, will be able to make good use of
> it and not require another format.
>
> To support this manually is impossible. To import it, you need clearence.
> To show it, you need applications.
> None of them are for the moment envisaged, so a link to the webaddress
> of the routes its dienstregeling will be at the time being the best to
> offer eg:
> http://reisinfo.delijn.be/dienstregelingen/
> Also the amount of data is also substantial, which may not be desired to
> incorporate it yet at this time.
>
> Also the last days, the names  of the relations are changed  with
> internal numbers of  De Lijn.
> This may confuse the user who will not retrieve the numbers as used on
> the bus, road maps, stop signs, etc by De Lijn.
> The name should be clear so that a user can easy retrieve ithe presence
> of a route. (Else he could start to map again the line and afterwards
> discover that his work was in vain)
> Furthermore, I believe these data are not public available and retrieved
> from an illegal database file, where we have no copyright to.
>
> So, I recommend:
> - to use only one relation per route
> - delete the doubles (backward routes).
> - delete child rel

Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ben Laenen
Ivo De Broeck wrote:
> Lijkt mij goed, alhoewel ik nog steeds niet begrijp wat die basisrelatie
> doet.

De basisrelatie is wat we kennen als een buslijn. Bus 20 in Antwerpen is een 
buslijn. Bus 20 in Leuven is een andere buslijn.

De segmentrelaties van de basisrelatie vormen samen de route of routes van 
buslijn X.


> Per dag zijn er x bussen die y ritten maken. Soms zetten ze 15 op hun
> display, soms 13 of iets anders.

Dat is interessant voor De Lijn zelf, maar daar is een reiziger helemaal niks 
mee. Misschien dat je die data wel kan terugvinden in de data die De Lijn zou 
geven, maar die informatie heeft geen waarde voor OSM. We gaan toch geen 
relatie maken voor elke (fysische) bus die rondrijdt in België met de volgorde 
van verschillende ritten over verschillende buslijnen die ze achtereenvolgens 
uitvoert? Evenmin gaan we routes van en naar de stelplaatsen mappen.

> Is de basisrelatie een verzameling van al
> mogelijke ritten, die onder nummer 15 rijden?

Bus 15 in Gent is niet hetzelfde als bus 15 in Leuven uiteraard, dat zijn 
andere buslijnen.

> Ook de nachtbus 15 (mocht die
> bestaan)?

Meestal is het nachtnet totaal wat anders dan overdag (in Antwerpen krijgen ze 
toch ook andere nummers, nl. met een "N" ervoor). Hoe het in Leuven is weet ik 
niet. Staat de uurregeling van nachtbus 3 bij op de uurregeling van dagbus 3? 
Of is het een aparte uurregeling die ernaast hangt?


> Probleem is dat IMHO buslijn 15 niet bestaat, wel ritten van A
> naar B waarbij men 15 op het display zet.

Euh, in welk geval die bus een rit van buslijn 15 verzekert?

Ik hoop dat we nu ook al niet moeten gaan discussiëren over de definitie van 
een buslijn :-)



> Zoals je opmerkt is zelfs een naam voor die basisrelatie een ?.
> Wat raar is dat relaties niet automatisch een richting hebben. JOSM zet
> mooi alle wegvakken op orde (beginpunt en eindpunt).

Een orde wel, een richting niet noodzakelijk. Elk stuk van een route dat niet 
dubbelrichting is moet in principe een forward/backward role hebben.

Zolang editors niet de volgorde van de members in een relatie verzekeren zijn 
we gedoemd om forward/backward te gebruiken ipv een simpele tag die zegt dat 
de route enkelrichting is.

Maar wederen, dit is ook een discussie op het niveau van routerelaties, en 
hier niets terzake doend.

> Ik zou zeker geen
> forward/backward gebruiken. De bushalten nummeren is misschien het
> eenvoudigste (met 0 als start?)

Dat zijn de bushaltes. Bushaltes geven niks van orde aan de wegen. Je kan gaan 
zitten projecteren van bushaltes naar hun wegen, maar dat is ook veel werk.

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ivo De Broeck
Lijkt mij goed, alhoewel ik nog steeds niet begrijp wat die basisrelatie
doet. Per dag zijn er x bussen die y ritten maken. Soms zetten ze 15 op hun
display, soms 13 of iets anders. Is de basisrelatie een verzameling van al
mogelijke ritten, die onder nummer 15 rijden? Ook de nachtbus 15 (mocht die
bestaan)? Probleem is dat IMHO buslijn 15 niet bestaat, wel ritten van A
naar B waarbij men 15 op het display zet.
Zoals je opmerkt is zelfs een naam voor die basisrelatie een ?.
Wat raar is dat relaties niet automatisch een richting hebben. JOSM zet mooi
alle wegvakken op orde (beginpunt en eindpunt). Ik zou zeker geen
forward/backward gebruiken. De bushalten nummeren is misschien het
eenvoudigste (met 0 als start?)

Op 15 oktober 2010 17:55 schreef Ben Laenen  het
volgende:

> Misschien eens tijd voor een synthese voor wat we hebben:
>
> Voor een heel normaal geval nemen we als voorbeeld buslijn 15 gaande van
> Station naar Kerk via Park. Terminus in Station en in Kerk.
>
> De tags met (?) zullen nog eens bekeken moeten worden
>
>
> (1) basisrelatie voor de buslijn:
>
> type=route (?)
> route=bus (?)
> ref=15
> name=15 Station - Park - Kerk (?)
> colour=red
>
> Deze relaties bevat geen haltes of wegen, maar enkel andere relaties, de
> bussegmentrelaties.
>
> Het gaat hier niet echt om een routerelatie, dus de type en route moeten
> waarschijnlijk aangepast worden
>
>
> (2) bussegmentrelaties tussen de knooppunten. We nemen gewoon beide
> terminussen als knooppunt in dit voorbeeld.
>
> heenweg:
>
> type=route
> route=bus
> ref=15
> name=15 Kerk via Park (?)
> from=Station
> to=Kerk
> via=Park
>
> terugweg:
>
> type=route
> route=bus
> ref=15
> name=15 Station via Park (?)
> from=Kerk
> to=Station
> via=Park
>
> deze segmenten bevatten de nodige ways en haltes (vooral de laatste zijn
> het
> belangrijkste)
>
> elk segment behoort slechts toe aan één buslijn (gezamenlijke delen van
> routes
> zijn een ander probleem dat niet apart voor busroutes moet opgelost worden
> maar op het niveau van routerelaties -- segmentrelaties zijn een soort van
> routerelatie)
>
> Het zijn ook enkelrichtingsrelaties, dus de nodige forward/backward roles
> moeten ook ingevuld worden.
>
>
>
> Wat betreft de knooppunten:
>
> Enkel haltes waar de bus stopt kunnen knooppunten vormen.
>
> Je bent vrij om te kiezen hoeveel en waar er een knooppunt ligt (zo lang we
> geen echte data van De Lijn hebben en dus ook niks met schedules van doen
> hebben). Echter elke terminus heeft moet een knooppunt zijn. Een bus die
> een
> lus volgt kan slechts één terminus en dus ook één knooppunt hebben.
>
> Elke mogelijke variante (verkorte ritten, andere routes, haltes die niet
> bediend worden,...) tussen twee knooppunten krijgt een eigen
> bussegmentrelatie. Door goede keuze van de knooppunten (bv. op de plekken
> waar
> een ingekorte rit eindigt of op de splitsing van twee wegen waar de
> variante
> route afwijkt van de normale weg) kan je het aantal stukken waar meerdere
> bussegmenten voor dezelfde buslijn nodig zijn serieus beperken.
>
> Als een bus eenzelfde weg twee keer aflegt in de heenweg omdat het vanaf
> een
> drukke weg een afgelegen wijk aandoet om dan terug naar die drukke weg gaat
> om
> verder te rijden, is het interessant (maar niet noodzakelijk) om een
> knooppunt
> te leggen in die afgelegen wijk om te vermijden dat je dezelfde weg twee
> keer
> in hetzelfde bussegment moet steken (Potlatch weigert dit sowieso en kan er
> rare dingen mee doen, JOSM geeft enkel een grote waarschuwing maar werkt er
> wel correct mee).
>
> De knooppunthaltes behoren steeds tot alle segmentrelaties die die als
> eind-
> of beginpunt hebben. In het simpelste geval van hierboven is de terminus
> Station dus terug te vinden in beide segmentrelaties. Bij een lus met één
> knooppunt zit dat knooppunt twee keer in de enige segmentrelatie die die
> buslijn heeft.
>
>
>
> Nog over na te denken:
>
> member roles: moeten de haltes in een relatie een volgnummer krijgen in hun
> role ter bescherming van editors die de volgorde om zeep helpen? Hebben
> terminussen een speciale role nodig?
>
> niet vergeten dat we ook de andere vormen van openbaar vervoer (tram,
> trein,
> metro en in Limburg straks ook lightrail) moeten kunnen inpassen in deze
> structuur (belangrijk voor keuze van typetag voor basisrelatie)
>
>
> en waarschijnlijk nog wel een paar dingetjes, maar ik denk dat dit ongeveer
> is
> waar we nu staan?
>
> Ben
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ben Laenen
Misschien eens tijd voor een synthese voor wat we hebben:

Voor een heel normaal geval nemen we als voorbeeld buslijn 15 gaande van 
Station naar Kerk via Park. Terminus in Station en in Kerk.

De tags met (?) zullen nog eens bekeken moeten worden


(1) basisrelatie voor de buslijn:

type=route (?)
route=bus (?)
ref=15
name=15 Station - Park - Kerk (?)
colour=red

Deze relaties bevat geen haltes of wegen, maar enkel andere relaties, de 
bussegmentrelaties.

Het gaat hier niet echt om een routerelatie, dus de type en route moeten 
waarschijnlijk aangepast worden


(2) bussegmentrelaties tussen de knooppunten. We nemen gewoon beide 
terminussen als knooppunt in dit voorbeeld.

heenweg:

type=route
route=bus
ref=15
name=15 Kerk via Park (?)
from=Station
to=Kerk
via=Park

terugweg:

type=route
route=bus
ref=15
name=15 Station via Park (?)
from=Kerk
to=Station
via=Park

deze segmenten bevatten de nodige ways en haltes (vooral de laatste zijn het 
belangrijkste)

elk segment behoort slechts toe aan één buslijn (gezamenlijke delen van routes 
zijn een ander probleem dat niet apart voor busroutes moet opgelost worden 
maar op het niveau van routerelaties -- segmentrelaties zijn een soort van 
routerelatie)

Het zijn ook enkelrichtingsrelaties, dus de nodige forward/backward roles 
moeten ook ingevuld worden.



Wat betreft de knooppunten:

Enkel haltes waar de bus stopt kunnen knooppunten vormen.

Je bent vrij om te kiezen hoeveel en waar er een knooppunt ligt (zo lang we 
geen echte data van De Lijn hebben en dus ook niks met schedules van doen 
hebben). Echter elke terminus heeft moet een knooppunt zijn. Een bus die een 
lus volgt kan slechts één terminus en dus ook één knooppunt hebben.

Elke mogelijke variante (verkorte ritten, andere routes, haltes die niet 
bediend worden,...) tussen twee knooppunten krijgt een eigen 
bussegmentrelatie. Door goede keuze van de knooppunten (bv. op de plekken waar 
een ingekorte rit eindigt of op de splitsing van twee wegen waar de variante 
route afwijkt van de normale weg) kan je het aantal stukken waar meerdere 
bussegmenten voor dezelfde buslijn nodig zijn serieus beperken.

Als een bus eenzelfde weg twee keer aflegt in de heenweg omdat het vanaf een 
drukke weg een afgelegen wijk aandoet om dan terug naar die drukke weg gaat om 
verder te rijden, is het interessant (maar niet noodzakelijk) om een knooppunt 
te leggen in die afgelegen wijk om te vermijden dat je dezelfde weg twee keer 
in hetzelfde bussegment moet steken (Potlatch weigert dit sowieso en kan er 
rare dingen mee doen, JOSM geeft enkel een grote waarschuwing maar werkt er 
wel correct mee).

De knooppunthaltes behoren steeds tot alle segmentrelaties die die als eind- 
of beginpunt hebben. In het simpelste geval van hierboven is de terminus 
Station dus terug te vinden in beide segmentrelaties. Bij een lus met één 
knooppunt zit dat knooppunt twee keer in de enige segmentrelatie die die 
buslijn heeft.



Nog over na te denken:

member roles: moeten de haltes in een relatie een volgnummer krijgen in hun 
role ter bescherming van editors die de volgorde om zeep helpen? Hebben 
terminussen een speciale role nodig?

niet vergeten dat we ook de andere vormen van openbaar vervoer (tram, trein, 
metro en in Limburg straks ook lightrail) moeten kunnen inpassen in deze 
structuur (belangrijk voor keuze van typetag voor basisrelatie)


en waarschijnlijk nog wel een paar dingetjes, maar ik denk dat dit ongeveer is 
waar we nu staan?

Ben


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


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ivo De Broeck
Op 15 oktober 2010 15:26 schreef Jo  het volgende:

> Ja, de bushaltes horen niet in de gemeenschappelijke routedelen. Wat ik
> zoveel mogelijk wil vermijden is duplicatie van informatie. Dat er in de
> 'name' de operator, het refnummer, from to en via herhaald wordt, zodat we
> zouden weten waarover het gaat, vind 'k niet meer dan normaal. Maar de
> segmenten zou 'k zoveel mogelijk gegroepeerd willen zien in logische groepen
> die herbruikt kunnen worden. Dat zouden we ook voor de bushaltes moeten
> kunnen gedaan krijgen.


ja maar jij zal dat kunnen onderhouden totdat iemand anders "ergens" iets
corrigeert.
waarom in 'name' niet gewoon plaatsen wat op de bus staat? dus "8 - Bierbeek
De Borre - via Bremt"

>
> Dat er niemand meer meeleest of reageert is op zich niet zo erg, we hebben
> toch al overleg tussen 3 personen.
>

;-)

>
> Het probleem met een simpele oplossing (die uiteraard altijd de voorkeur
> moet krijgen), is dat het hele gegeven niet simpel is. De manier om dat in
> in computernetwerken op te lossen, is door met verschillende lagen te werken
> en dat is wat we hier aan het doen zijn.
>
> Jo
>

1 relatie voor 1 busrit lijkt me niet zo ingewikkeld.
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ivo De Broeck
Ik lees nog ;-), maar ik denk dat je een punt hebt. Liefst een simpele en
duidelijke oplossing. Kunnen we het eens worden over het mappen van een
busrit (daar blijf ik wel van overtuigd dat we die in aparte relaties moeten
steken en koppelen aan de juiste bus_stops).

Op 15 oktober 2010 15:00 schreef Ben Laenen  het
volgende:

> Jo wrote:
> > En dat is dus wat ik bedoelde met extra complexiteit voor de mapper.
> > Uiteindelijk maakt het het eenvoudiger (1x werk, i.p.v. 68x bij
> onderhoud),
> > maar je moet wel doorheen verschillende lagen en er het hoofd bijhouden
> wat
> > in welke laag thuishoort.
> >
> > Als wij het zo mappen, dan zullen er renderers moeten worden gemaakt die
> > het ook zo weergeven. Dat zullen we waarschijnlijk zelf moeten aanpakken.
> > Het heeft geen zin om te wachten tot iemand het voor ons doet.
>
> Maar wat ik wel dus zei is dat dit voor het niveau onder
> busroutesegmentenrelaties is omdat deze bussegmenten volgens mij meer nodig
> hebben qua tags of member roles. En je moet bvb. vanuit een scheduler
> kunnen
> linken naar busroutesegmenten, en bushaltes horen wat mij betreft ook thuis
> in
> de busroutesegmenten en niet in de gemeenschappelijke routedelen.
>
> Dus daarmee dat ik het niet echt nodig vind om dit nu te bediscussiëren.
> Dit
> kan later ook op het niveau van alle routerelaties -- fiets-, wandel, bus,
> wegnummer-, spoorwegroutes, etc. (en dit zal sowieso internationaal moeten,
> buslijnen kunnen we nog op Belgisch niveau doen). Deze discussie kon nl.
> ook
> voor buslijnen die gewoon met één relatie gemapt worden. Het is allemaal al
> ingewikkeld genoeg zonder dit ook nog ineens mee te nemen (en ik vraag me
> af
> of hoeveel er op de mailinglijst dit nog allemaal aan het lezen zijn :-) )
>
> Ben
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Jo
Ja, de bushaltes horen niet in de gemeenschappelijke routedelen. Wat ik
zoveel mogelijk wil vermijden is duplicatie van informatie. Dat er in de
'name' de operator, het refnummer, from to en via herhaald wordt, zodat we
zouden weten waarover het gaat, vind 'k niet meer dan normaal. Maar de
segmenten zou 'k zoveel mogelijk gegroepeerd willen zien in logische groepen
die herbruikt kunnen worden. Dat zouden we ook voor de bushaltes moeten
kunnen gedaan krijgen.

Dat er niemand meer meeleest of reageert is op zich niet zo erg, we hebben
toch al overleg tussen 3 personen.

Het probleem met een simpele oplossing (die uiteraard altijd de voorkeur
moet krijgen), is dat het hele gegeven niet simpel is. De manier om dat in
in computernetwerken op te lossen, is door met verschillende lagen te werken
en dat is wat we hier aan het doen zijn.

Jo

Op 15 oktober 2010 15:00 schreef Ben Laenen  het
volgende:

> Jo wrote:
> > En dat is dus wat ik bedoelde met extra complexiteit voor de mapper.
> > Uiteindelijk maakt het het eenvoudiger (1x werk, i.p.v. 68x bij
> onderhoud),
> > maar je moet wel doorheen verschillende lagen en er het hoofd bijhouden
> wat
> > in welke laag thuishoort.
> >
> > Als wij het zo mappen, dan zullen er renderers moeten worden gemaakt die
> > het ook zo weergeven. Dat zullen we waarschijnlijk zelf moeten aanpakken.
> > Het heeft geen zin om te wachten tot iemand het voor ons doet.
>
> Maar wat ik wel dus zei is dat dit voor het niveau onder
> busroutesegmentenrelaties is omdat deze bussegmenten volgens mij meer nodig
> hebben qua tags of member roles. En je moet bvb. vanuit een scheduler
> kunnen
> linken naar busroutesegmenten, en bushaltes horen wat mij betreft ook thuis
> in
> de busroutesegmenten en niet in de gemeenschappelijke routedelen.
>
> Dus daarmee dat ik het niet echt nodig vind om dit nu te bediscussiëren.
> Dit
> kan later ook op het niveau van alle routerelaties -- fiets-, wandel, bus,
> wegnummer-, spoorwegroutes, etc. (en dit zal sowieso internationaal moeten,
> buslijnen kunnen we nog op Belgisch niveau doen). Deze discussie kon nl.
> ook
> voor buslijnen die gewoon met één relatie gemapt worden. Het is allemaal al
> ingewikkeld genoeg zonder dit ook nog ineens mee te nemen (en ik vraag me
> af
> of hoeveel er op de mailinglijst dit nog allemaal aan het lezen zijn :-) )
>
> Ben
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ben Laenen
Jo wrote:
> En dat is dus wat ik bedoelde met extra complexiteit voor de mapper.
> Uiteindelijk maakt het het eenvoudiger (1x werk, i.p.v. 68x bij onderhoud),
> maar je moet wel doorheen verschillende lagen en er het hoofd bijhouden wat
> in welke laag thuishoort.
> 
> Als wij het zo mappen, dan zullen er renderers moeten worden gemaakt die
> het ook zo weergeven. Dat zullen we waarschijnlijk zelf moeten aanpakken.
> Het heeft geen zin om te wachten tot iemand het voor ons doet.

Maar wat ik wel dus zei is dat dit voor het niveau onder 
busroutesegmentenrelaties is omdat deze bussegmenten volgens mij meer nodig 
hebben qua tags of member roles. En je moet bvb. vanuit een scheduler kunnen 
linken naar busroutesegmenten, en bushaltes horen wat mij betreft ook thuis in 
de busroutesegmenten en niet in de gemeenschappelijke routedelen.

Dus daarmee dat ik het niet echt nodig vind om dit nu te bediscussiëren. Dit 
kan later ook op het niveau van alle routerelaties -- fiets-, wandel, bus, 
wegnummer-, spoorwegroutes, etc. (en dit zal sowieso internationaal moeten, 
buslijnen kunnen we nog op Belgisch niveau doen). Deze discussie kon nl. ook 
voor buslijnen die gewoon met één relatie gemapt worden. Het is allemaal al 
ingewikkeld genoeg zonder dit ook nog ineens mee te nemen (en ik vraag me af 
of hoeveel er op de mailinglijst dit nog allemaal aan het lezen zijn :-) )

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Jo
Op 15 oktober 2010 13:03 schreef Ben Laenen  het
volgende:

> Jo wrote:
> > De reden waarom ik met child relations was beginnen te werken, was om de
> > gemeenschappelijke stukken asfalt waar ze over rijden slechts 1 keer te
> > moeten ingeven.
> >
> > Door de Bondgenotenlaan van Leuven razen de volgende lijnen:
> >
> 1,2,3,4,5,6,7,8,9,284,285,310,315,316,317,333,334,335,337,351,352,358,370,3
> > 71,372,373,374,380 en 395. Vind je het dan gek dat 'k dat stukje traject
> in
> > 1 relatie zou willen gieten en hergebruiken. Op dit moment is er een
> > omleiding (en dat komt vaker voor). Word er dan echt verwacht van een
> > mapper dat hij 29x2 keer hetzelfde werk doet om al die omleidingen in te
> > geven? En dat is nog maar een extreem voorbeeld, maar zo zijn er
> > tientallen, rondom Leuven alleen al. Misschien hebben ze in grotere
> steden
> > minder asfalt gemeenschappelijk, maar dat denk 'k eigenlijk niet. Alle 8x
> > lijnen in Gent rijden van het
> > Sint-Pietersstation tot aan het Zuid dezelfde route.
>
>
> Ik ken zeker het probleem. In Antwerpen staan sommige wegen ook vol
> busfiles
> vanwege de vele buslijnen die ze er laten passeren (waarom ze ook alles per
> se
> naar de Rooseveltplaats willen sturen ipv overstappunten aan de rand van de
> stad...).
>
>
> Maar wat je wil is eigenlijk een structuur op routerelaties dat eigenlijk
> los
> van onze discussie staat. Het is al sinds het invoeren van relaties dat we
> het
> wel leuk zouden vinden om een relatie te hebben die deel kan zijn van
> verschillende routerelaties waarbij die relatie automatisch als een deel
> van
> de route geldt. Dit is bijvoorbeeld ook nuttig bij twee fietsroutes die een
> deel van de route samenvallen. Zorg dat dit op een manier in OSM
> ondersteund
> wordt (en dat het vooral opgepikt wordt door renderers en al wie gebruik
> maakt
> van de relaties), en je kan er meteen ook gebruik van maken bij busroutes.
> Ik
> weet dat er een paar kleine pogingen gedaan zijn hiervoor, maar of het al
> ergens echt werkt?
>
> Wat mij betreft doet de vraag op dit moment of verschillende
> busroutesegmenten
> gedeeld kunnen worden er eigenlijk dus nog niet toe, omdat een
> busroutesegment
> meer is dan enkel een stuk route. Het zouden in dit geval deze
> busroutesegmenten zijn die op hun beurt relaties zouden kunnen bevatten die
> gemeenschappelijke stukken route volgen.
>
> Natuurlijk gaan we zo al op drie niveaus van relaties (of meer, die
> routerelaties zouden zelf ook op hun beurt routerelaties kunnen bevatten),
> en
> voor de modale mapper gaat dit ook best moeilijk zijn zonder de nodige
> tools
> om dat tot een goed einde te brengen...
>
> Ben
>
> En dat is dus wat ik bedoelde met extra complexiteit voor de mapper.
Uiteindelijk maakt het het eenvoudiger (1x werk, i.p.v. 68x bij onderhoud),
maar je moet wel doorheen verschillende lagen en er het hoofd bijhouden wat
in welke laag thuishoort.

Als wij het zo mappen, dan zullen er renderers moeten worden gemaakt die het
ook zo weergeven. Dat zullen we waarschijnlijk zelf moeten aanpakken. Het
heeft geen zin om te wachten tot iemand het voor ons doet.

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


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ben Laenen
Jo wrote:
> De reden waarom ik met child relations was beginnen te werken, was om de
> gemeenschappelijke stukken asfalt waar ze over rijden slechts 1 keer te
> moeten ingeven.
> 
> Door de Bondgenotenlaan van Leuven razen de volgende lijnen:
> 1,2,3,4,5,6,7,8,9,284,285,310,315,316,317,333,334,335,337,351,352,358,370,3
> 71,372,373,374,380 en 395. Vind je het dan gek dat 'k dat stukje traject in
> 1 relatie zou willen gieten en hergebruiken. Op dit moment is er een
> omleiding (en dat komt vaker voor). Word er dan echt verwacht van een
> mapper dat hij 29x2 keer hetzelfde werk doet om al die omleidingen in te
> geven? En dat is nog maar een extreem voorbeeld, maar zo zijn er
> tientallen, rondom Leuven alleen al. Misschien hebben ze in grotere steden
> minder asfalt gemeenschappelijk, maar dat denk 'k eigenlijk niet. Alle 8x
> lijnen in Gent rijden van het
> Sint-Pietersstation tot aan het Zuid dezelfde route.


Ik ken zeker het probleem. In Antwerpen staan sommige wegen ook vol busfiles 
vanwege de vele buslijnen die ze er laten passeren (waarom ze ook alles per se 
naar de Rooseveltplaats willen sturen ipv overstappunten aan de rand van de 
stad...).


Maar wat je wil is eigenlijk een structuur op routerelaties dat eigenlijk los 
van onze discussie staat. Het is al sinds het invoeren van relaties dat we het 
wel leuk zouden vinden om een relatie te hebben die deel kan zijn van 
verschillende routerelaties waarbij die relatie automatisch als een deel van 
de route geldt. Dit is bijvoorbeeld ook nuttig bij twee fietsroutes die een 
deel van de route samenvallen. Zorg dat dit op een manier in OSM ondersteund 
wordt (en dat het vooral opgepikt wordt door renderers en al wie gebruik maakt 
van de relaties), en je kan er meteen ook gebruik van maken bij busroutes. Ik 
weet dat er een paar kleine pogingen gedaan zijn hiervoor, maar of het al 
ergens echt werkt?

Wat mij betreft doet de vraag op dit moment of verschillende busroutesegmenten 
gedeeld kunnen worden er eigenlijk dus nog niet toe, omdat een busroutesegment 
meer is dan enkel een stuk route. Het zouden in dit geval deze 
busroutesegmenten zijn die op hun beurt relaties zouden kunnen bevatten die 
gemeenschappelijke stukken route volgen.

Natuurlijk gaan we zo al op drie niveaus van relaties (of meer, die 
routerelaties zouden zelf ook op hun beurt routerelaties kunnen bevatten), en 
voor de modale mapper gaat dit ook best moeilijk zijn zonder de nodige tools 
om dat tot een goed einde te brengen...

Ben


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


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Jo
Hier is mijn poging met lijn 4 in Leuven:

Overkoepelende relatie:
http://www.openstreetmap.org/browse/relation/
1225834

Bevat enkel relaties van het volgende type:

Van Haasrode naar Herent:
http://www.openstreetmap.org/browse/relation/
1225633

Van Herent naar Haasrode:
http://www.openstreetmap.org/browse/relation/119762

Deze kunnen zowel ways als child relations bevatten:

Nu volgt een greep uit de relaties waar gebruik van wordt gemaakt:


http://www.openstreetmap.org/browse/relation/1190916

Stuk over Bondgenotenlaan:
http://www.openstreetmap.org/browse/relation/1189154

Het stuk Tiensevest dat over het Martelarenplein loopt waar de bus 2x
overgaat, zit op deze manier in 2 verschillende child relations. Ik heb nu
de weg ingegeven zoals hij hoort te rijden. Er zijn echter 2 omleidingen.
Eén voor een 2 jaar durend vernieuwingsproject aan de Geldenaaksebaan en een
andere voor de aanpassing van het Fochplein (zal wschl ook 2 jaar duren).
Door de child relations aan te passen voor de Geldenaaksebaan, is dit voor 3
lijnen tegelijk verwezenlijkt. Door de child relations aan te passen voor
het traject tussen Station en Fochplein is dit voor 29 lijnen tegelijk in
orde.

mvg,

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


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Jo
Op 15 oktober 2010 09:21 schreef Ivo De Broeck  het
volgende:

> Op 14 oktober 2010 23:48 schreef Jo  het volgende:
>
>> De reden waarom ik met child relations was beginnen te werken, was om de
>> gemeenschappelijke stukken asfalt waar ze over rijden slechts 1 keer te
>> moeten ingeven.
>>
>> Door de Bondgenotenlaan van Leuven razen de volgende lijnen:
>> 1,2,3,4,5,6,7,8,9,284,285,310,315,316,317,333,334,335,337,351,352,358,370,371,372,373,374,380
>> en 395. Vind je het dan gek dat 'k dat stukje traject in 1 relatie zou
>> willen gieten en hergebruiken. Op dit moment is er een omleiding (en dat
>> komt vaker voor). Word er dan echt verwacht van een mapper dat hij 29x2 keer
>> hetzelfde werk doet om al die omleidingen in te geven? En dat is nog maar
>> een extreem voorbeeld, maar zo zijn er tientallen, rondom Leuven alleen al.
>> Misschien hebben ze in grotere steden minder asfalt gemeenschappelijk, maar
>> dat denk 'k eigenlijk niet. Alle 8x lijnen in Gent rijden van het
>> Sint-Pietersstation tot aan het Zuid dezelfde route.
>>
>> Jo
>>
>
> Ik denk dat jullie op het goede spoor zitten. Wel 1 opmerking betreffende
> die "places" van 'De Lijn". Zijn die eigenlijk relevant? Uiteindelijk doet
> "De Lijn" ritten van A naar B (met 1 vertrekuur en 1 aankomstuur). Verder
> rijden er wat bussen rond met "geen dienst", rijden bussen 1 of 2 maal per
> dag naar een stelplaats , enz
>
> Hier een overzicht van zogenaamde places:
>
> 1) Bertem Rond Punt : lijnen 7,8 en 9 de bussen draaien gewoon terug via
> een rond punt op 50m van de bushalten "Rond Punt"
> uitzonderingen
> om 6:52 vertrekt bus 9 vanuit de stelplaats St-Bernardus en bediend "rond
> Punt" om 6:54
> om 13:07 zelfde verhaal voor bus 8
> om 18:07 idem voor (nogmaals) bus 8
>

Wat ons interesseert, is wanneer hij vertrekt op halte Rond Punt.

>
> 2) Bierbeek De Borre lijnen 7 en 8: de bus zet zich even aan de kant 100m
> verder en begint dan een nieuwe rit.
>
> 3) Pimberg is eindhalte en beginhalte nieuwe rit, staat daar meestal een 15
> min "te wachten"
>
> 4) Verkorte rit Bremt : ben je daar zeker van Jo? Volgens mij rijdt die bus
> altijd door tot De Borre
>

Pertinent zeker. Heb het 1 keer meegemaakt dat 'k niet had opgelet wat er op
de film stond en dat die mij daar afzette. Op zo'n moment ben je content dat
je een plooifietsje mee hebt.

>
> Mijn vraag is of dit allemaal relevant is in OSM. Indien men de (logische)
> beslissing neemt een "rit" te beschrijven (route en halten) is dat niet ruim
> voldoende? Het idee van gemeenschappelijke stukken in childrelaties te
> steken lijkt ook mij nuttig, niet alleen op de Bondgenotenlaan.(zie
> netplannen).
>
> Indien routes afwijken bv gedurende het weekend, moeten we misschien iets
> voorzien voor 'Ma-Vr" en "Za-Zo"?
>

Ik denk dat, als we in OSM kunnen beschrijven waar ze rijden/stoppen en hoe
je van de ene halte/station/(vlieg)haven naar de andere of naar de
eindbestemming geraakt, dat een ander project daar dan op verder kan bouwen,
met informatie over wanneer ze rijden. Dus over het wanneer gaan we ons best
niet teveel zorgen maken. OK, het zou nog interessante informatie kunnen
zijn om bepaalde gedeeltes in stippellijn oid weer te geven. Misschien
kunnen we naast colour ook nog een tag alternative hebben? Of dat in de
overkoepelende relatie als rol meegeven.

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


Re: [OSM-talk-be] busroutes

2010-10-15 Thread Ivo De Broeck
Op 14 oktober 2010 23:48 schreef Jo  het volgende:

> De reden waarom ik met child relations was beginnen te werken, was om de
> gemeenschappelijke stukken asfalt waar ze over rijden slechts 1 keer te
> moeten ingeven.
>
> Door de Bondgenotenlaan van Leuven razen de volgende lijnen:
> 1,2,3,4,5,6,7,8,9,284,285,310,315,316,317,333,334,335,337,351,352,358,370,371,372,373,374,380
> en 395. Vind je het dan gek dat 'k dat stukje traject in 1 relatie zou
> willen gieten en hergebruiken. Op dit moment is er een omleiding (en dat
> komt vaker voor). Word er dan echt verwacht van een mapper dat hij 29x2 keer
> hetzelfde werk doet om al die omleidingen in te geven? En dat is nog maar
> een extreem voorbeeld, maar zo zijn er tientallen, rondom Leuven alleen al.
> Misschien hebben ze in grotere steden minder asfalt gemeenschappelijk, maar
> dat denk 'k eigenlijk niet. Alle 8x lijnen in Gent rijden van het
> Sint-Pietersstation tot aan het Zuid dezelfde route.
>
> Jo
>

Ik denk dat jullie op het goede spoor zitten. Wel 1 opmerking betreffende
die "places" van 'De Lijn". Zijn die eigenlijk relevant? Uiteindelijk doet
"De Lijn" ritten van A naar B (met 1 vertrekuur en 1 aankomstuur). Verder
rijden er wat bussen rond met "geen dienst", rijden bussen 1 of 2 maal per
dag naar een stelplaats , enz

Hier een overzicht van zogenaamde places:

1) Bertem Rond Punt : lijnen 7,8 en 9 de bussen draaien gewoon terug via een
rond punt op 50m van de bushalten "Rond Punt"
uitzonderingen
om 6:52 vertrekt bus 9 vanuit de stelplaats St-Bernardus en bediend "rond
Punt" om 6:54
om 13:07 zelfde verhaal voor bus 8
om 18:07 idem voor (nogmaals) bus 8

2) Bierbeek De Borre lijnen 7 en 8: de bus zet zich even aan de kant 100m
verder en begint dan een nieuwe rit.

3) Pimberg is eindhalte en beginhalte nieuwe rit, staat daar meestal een 15
min "te wachten"

4) Verkorte rit Bremt : ben je daar zeker van Jo? Volgens mij rijdt die bus
altijd door tot De Borre

Mijn vraag is of dit allemaal relevant is in OSM. Indien men de (logische)
beslissing neemt een "rit" te beschrijven (route en halten) is dat niet ruim
voldoende? Het idee van gemeenschappelijke stukken in childrelaties te
steken lijkt ook mij nuttig, niet alleen op de Bondgenotenlaan.(zie
netplannen).

Indien routes afwijken bv gedurende het weekend, moeten we misschien iets
voorzien voor 'Ma-Vr" en "Za-Zo"?
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Jo
De reden waarom ik met child relations was beginnen te werken, was om de
gemeenschappelijke stukken asfalt waar ze over rijden slechts 1 keer te
moeten ingeven.

Door de Bondgenotenlaan van Leuven razen de volgende lijnen:
1,2,3,4,5,6,7,8,9,284,285,310,315,316,317,333,334,335,337,351,352,358,370,371,372,373,374,380
en 395. Vind je het dan gek dat 'k dat stukje traject in 1 relatie zou
willen gieten en hergebruiken. Op dit moment is er een omleiding (en dat
komt vaker voor). Word er dan echt verwacht van een mapper dat hij 29x2 keer
hetzelfde werk doet om al die omleidingen in te geven? En dat is nog maar
een extreem voorbeeld, maar zo zijn er tientallen, rondom Leuven alleen al.
Misschien hebben ze in grotere steden minder asfalt gemeenschappelijk, maar
dat denk 'k eigenlijk niet. Alle 8x lijnen in Gent rijden van het
Sint-Pietersstation tot aan het Zuid dezelfde route.

Jo

Op 14 oktober 2010 21:57 schreef Ben Laenen  het
volgende:

>
> Dat is gewoon hetzelfde? Buslijnen hebben geen relaties met mekaar gemeen.
>
>
> Jo wrote:
> > OK, doe nu een lijn die een stuk gemeenschappelijk heeft met lijn 14.
> >
> > Jo
> >
> > Op 14 oktober 2010 20:29 schreef Ben Laenen  het
> >
> > volgende:
> > > Jo wrote:
> > > > Ja, misschien wel, want het is me niet bepaald duidelijk. Kunnen die
> > > > segmentrelaties door meerdere lijnen gebruikt worden? (Dat is waar ik
> > > > vanuit ging en wschl de bron van de verwarring.) Het is pas als die
> > > > segmentrelaties door meerdere lijnen herbruikt kunnen worden, dat het
> > > > interessant wordt vanuit het standpunt van onderhoudbaarheid van de
> > > > gegevens.
> > >
> > > Heb eens een testje gedaan voor bus 14 in Antwerpen (die liep toch nog
> > > langs
> > > de verkeerde wegen in OSM sinds die een andere route volgt). Ze is nog
> > > niet volledig en ik heb ook niet alle bushaltes langs de route, maar
> het
> > > geeft een
> > > idee:
> > >
> > > Bus 14 is misschien niet de meest interessante route, ze is een gewone
> > > stadslijn en heeft twee knooppunten: beide terminussen. Verder ook geen
> > > speciale situaties zoals varianten.
> > >
> > > http://www.openstreetmap.org/browse/relation/11157
> > > is de basisrelatie. Zoals je ziet bestaat ze uit twee routesegmenten
> (de
> > > heenweg en de terugweg). Deze zijn:
> > >
> > > http://www.openstreetmap.org/browse/relation/1225296
> > > http://www.openstreetmap.org/browse/relation/1225297
> > >
> > > Zo eenvoudig is het dus eigenlijk. Qua vorm heeft het alles weg van de
> > > door mij steeds verketterde twee relaties, maar qua structuur past het
> > > nu tenminste
> > > in iets dat meer kan met bv. willekeurig aantal knooppunten (inclusief
> > > één knooppunt)
> > >
> > > Nog enkele opmerkingen:
> > > * de volgorde van de ways onderling en van de haltes onderling in de
> > > relatie
> > > is belangrijk en moet op een manier zien bewaard te blijven -- kwestie
> > > van tijd eigenlijk tot Potlatch of een andere editor dat om zeep
> > > helpt... * niet te veel kijken naar de tags van de relatie. Dat is pas
> > > voor later. Ook
> > > voor de member roles van de haltes moet misschien nog een en ander
> gezegd
> > > worden
> > >
> > >
> > > De data van De Lijn maakt het trouwens niet echt makkelijk hier, die
> > > hebben eigenlijk het equivalent van een relatie voor elke bus die
> rijdt.
> > > Dus een relatie voor de bus om 8u15, dan een relatie voor de bus om
> 8u30
> > > etc.
> > >
> > > Ze splitsen ook in veel minder knooppunten op dan ik eerst had gedacht,
> > > wat dan veel werk geeft bij variantes (vele stukken dubbel omdat de
> > > knooppunten ver uit elkaar liggen). Natuurlijk, zo lang we de data van
> > > De Lijn niet hebben
> > > kunnen we hier doen wat we willen en opsplitsen zo veel en zo graag we
> > > willen
> > >
> > > :-)
> > >
> > > Ben
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Jo
OK, doe nu een lijn die een stuk gemeenschappelijk heeft met lijn 14.

Ik doe ondertussen een gelijkaardige oefening met lijnen 4,5 en 6 in Leuven.

Jo

Op 14 oktober 2010 20:29 schreef Ben Laenen  het
volgende:

> Jo wrote:
> > Ja, misschien wel, want het is me niet bepaald duidelijk. Kunnen die
> > segmentrelaties door meerdere lijnen gebruikt worden? (Dat is waar ik
> > vanuit ging en wschl de bron van de verwarring.) Het is pas als die
> > segmentrelaties door meerdere lijnen herbruikt kunnen worden, dat het
> > interessant wordt vanuit het standpunt van onderhoudbaarheid van de
> > gegevens.
>
> Heb eens een testje gedaan voor bus 14 in Antwerpen (die liep toch nog
> langs
> de verkeerde wegen in OSM sinds die een andere route volgt). Ze is nog niet
> volledig en ik heb ook niet alle bushaltes langs de route, maar het geeft
> een
> idee:
>
> Bus 14 is misschien niet de meest interessante route, ze is een gewone
> stadslijn en heeft twee knooppunten: beide terminussen. Verder ook geen
> speciale situaties zoals varianten.
>
> http://www.openstreetmap.org/browse/relation/11157
> is de basisrelatie. Zoals je ziet bestaat ze uit twee routesegmenten (de
> heenweg en de terugweg). Deze zijn:
>
> http://www.openstreetmap.org/browse/relation/1225296
> http://www.openstreetmap.org/browse/relation/1225297
>
> Zo eenvoudig is het dus eigenlijk. Qua vorm heeft het alles weg van de door
> mij steeds verketterde twee relaties, maar qua structuur past het nu
> tenminste
> in iets dat meer kan met bv. willekeurig aantal knooppunten (inclusief één
> knooppunt)
>
> Nog enkele opmerkingen:
> * de volgorde van de ways onderling en van de haltes onderling in de
> relatie
> is belangrijk en moet op een manier zien bewaard te blijven -- kwestie van
> tijd eigenlijk tot Potlatch of een andere editor dat om zeep helpt...
> * niet te veel kijken naar de tags van de relatie. Dat is pas voor later.
> Ook
> voor de member roles van de haltes moet misschien nog een en ander gezegd
> worden
>
>
> De data van De Lijn maakt het trouwens niet echt makkelijk hier, die hebben
> eigenlijk het equivalent van een relatie voor elke bus die rijdt. Dus een
> relatie voor de bus om 8u15, dan een relatie voor de bus om 8u30 etc.
>
> Ze splitsen ook in veel minder knooppunten op dan ik eerst had gedacht, wat
> dan veel werk geeft bij variantes (vele stukken dubbel omdat de knooppunten
> ver uit elkaar liggen). Natuurlijk, zo lang we de data van De Lijn niet
> hebben
> kunnen we hier doen wat we willen en opsplitsen zo veel en zo graag we
> willen
> :-)
>
> Ben
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Ben Laenen
Jo wrote:
> Ja, misschien wel, want het is me niet bepaald duidelijk. Kunnen die
> segmentrelaties door meerdere lijnen gebruikt worden? (Dat is waar ik
> vanuit ging en wschl de bron van de verwarring.) Het is pas als die
> segmentrelaties door meerdere lijnen herbruikt kunnen worden, dat het
> interessant wordt vanuit het standpunt van onderhoudbaarheid van de
> gegevens.

Heb eens een testje gedaan voor bus 14 in Antwerpen (die liep toch nog langs 
de verkeerde wegen in OSM sinds die een andere route volgt). Ze is nog niet 
volledig en ik heb ook niet alle bushaltes langs de route, maar het geeft een 
idee:

Bus 14 is misschien niet de meest interessante route, ze is een gewone 
stadslijn en heeft twee knooppunten: beide terminussen. Verder ook geen 
speciale situaties zoals varianten.

http://www.openstreetmap.org/browse/relation/11157
is de basisrelatie. Zoals je ziet bestaat ze uit twee routesegmenten (de 
heenweg en de terugweg). Deze zijn:

http://www.openstreetmap.org/browse/relation/1225296
http://www.openstreetmap.org/browse/relation/1225297

Zo eenvoudig is het dus eigenlijk. Qua vorm heeft het alles weg van de door 
mij steeds verketterde twee relaties, maar qua structuur past het nu tenminste 
in iets dat meer kan met bv. willekeurig aantal knooppunten (inclusief één 
knooppunt)

Nog enkele opmerkingen:
* de volgorde van de ways onderling en van de haltes onderling in de relatie 
is belangrijk en moet op een manier zien bewaard te blijven -- kwestie van 
tijd eigenlijk tot Potlatch of een andere editor dat om zeep helpt...
* niet te veel kijken naar de tags van de relatie. Dat is pas voor later. Ook 
voor de member roles van de haltes moet misschien nog een en ander gezegd 
worden


De data van De Lijn maakt het trouwens niet echt makkelijk hier, die hebben 
eigenlijk het equivalent van een relatie voor elke bus die rijdt. Dus een 
relatie voor de bus om 8u15, dan een relatie voor de bus om 8u30 etc.

Ze splitsen ook in veel minder knooppunten op dan ik eerst had gedacht, wat 
dan veel werk geeft bij variantes (vele stukken dubbel omdat de knooppunten 
ver uit elkaar liggen). Natuurlijk, zo lang we de data van De Lijn niet hebben 
kunnen we hier doen wat we willen en opsplitsen zo veel en zo graag we willen 
:-)

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Ben Laenen
Jo wrote:
> Ja, misschien wel, want het is me niet bepaald duidelijk. Kunnen die
> segmentrelaties door meerdere lijnen gebruikt worden? (Dat is waar ik
> vanuit ging en wschl de bron van de verwarring.) Het is pas als die
> segmentrelaties door meerdere lijnen herbruikt kunnen worden, dat het
> interessant wordt vanuit het standpunt van onderhoudbaarheid van de
> gegevens.

Nee, segmentrelaties behoren maar aan één buslijn toe, toch in wat ik voor 
ogen heb.

Misschien dat het kan uitgebreid worden dat een segment tot meerdere buslijnen 
kan behoren, maar of/hoe dat werkt heb ik nog niet bekeken... Of het 
makkelijker is in onderhoud durf ik ook te betwijfelen.

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Jo
Op 14 oktober 2010 15:35 schreef Ben Laenen  het
volgende:

> Jo wrote:
>
> > Wel, de haltes in de segmenten steken, lijkt me problematisch om 2
> redenen:
> > ten eerste doen snelbussen niet alle haltes aan
>
> En in dat geval zitten de haltes ook niet in die segmentrelaties. Je zet
> een
> bushalte enkel in een relatie als de bus er ook werkelijk stopt.
>
> > en ten tweede is het
> > interessant om op het niveau van de haltes te kunnen zien door welke
> > route(relatie)s ze gebruikt worden. (om dit dan te vergelijken met wat er
> > in 'lines'   zit. Die 'lines' zijn er dan enkel maar ter verificatie, of
> > om ook al een idee te hebben welke buslijnen deze halte aandoen, voordat
> > alle routerelaties zijn aangemaakt.
>
> Blijkbaar is de structuur nog niet geheel duidelijk:
>


Van geen kanten, vandaar m'n verdere vragen.

>
> * basisrelatie voor elke buslijn
> * die relatie heeft een aantal knooppunten onderweg (neem 4 in totaal: 2
> terminussen en 2 middenin de route) -- knooppunten die niet speciaal getagd
> worden
> * laten we nu even stellen dat er geen variantes zijn, dan zijn dit dus 8
> relaties die in de basisrelatie moeten zitten (tussen elk knooppunt één
> voor
> heen en één voor terug)
> * welke wegen gevolgd worden is eigenlijk maar in tweede instantie
> belangrijk,
> het belangrijkste is dat elk segmentrelatie een lijst van haltes heeft (de
> wegen gaan we toch ook nooit automatisch kunnen importeren)
>
>
> Wat betekent dat dus voor een bushalte: die zal tot een aantal
> segmentrelaties
> behoren. Welke buslijnen daar dan stoppen kan je vinden door te kijken tot
> welke relatie die segmentrelatie toebehoort.
>
>
> Moest je nu een variante hebben die op bepaalde uren van de dag niet aan
> bushalte X stopt, dan zijn er tussen de knooppunten in de heenrichting twee
> segmentrelaties: één die de bushalte X bevat, en één die de bushalte X niet
> bevat.
>
>
> > > Eén relatie: bus 8
> > > Met daarin een aantal andere relaties die op hun beurt dan de
> > > to/from/via hebben die voor dat stuk op de bus of halte staan.
> >
> > Ik krijg de indruk dat we over 3 niveaus van relaties aan het spreken
> zijn.
> > 1 relatie voor bus 3308, meerdere relaties voor alle mogelijke varianten
> en
> > richtingen, dewelke gebruik maken van relaties die 'strategische nodes'
> met
> > elkaar verbinden.
>
> Nee, ik heb het over twee niveaus: basisrelatie voor elke buslijn,
> segmentrelaties voor de routes (al is het eerder lijst van haltes).
>
> Als tussen X en Y in de heenrichting twee varianten zijn, dan zijn er twee
> segmentrelaties voor de heenrichting tussen X en Y. Het is aan de scheduler
> om
> de juiste van de twee te kiezen.
>
> 't Is dus niet zo dat er nog meer groeperingen zijn.
>
>
> Misschien dat er eens een voorbeeld in OSM moet worden gezet om het te
> verduidelijken :-)
>
> Ben
>
Ja, misschien wel, want het is me niet bepaald duidelijk. Kunnen die
segmentrelaties door meerdere lijnen gebruikt worden? (Dat is waar ik vanuit
ging en wschl de bron van de verwarring.) Het is pas als die segmentrelaties
door meerdere lijnen herbruikt kunnen worden, dat het interessant wordt
vanuit het standpunt van onderhoudbaarheid van de gegevens.

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


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Ben Laenen
Jo wrote:

> Wel, de haltes in de segmenten steken, lijkt me problematisch om 2 redenen:
> ten eerste doen snelbussen niet alle haltes aan

En in dat geval zitten de haltes ook niet in die segmentrelaties. Je zet een 
bushalte enkel in een relatie als de bus er ook werkelijk stopt.

> en ten tweede is het
> interessant om op het niveau van de haltes te kunnen zien door welke
> route(relatie)s ze gebruikt worden. (om dit dan te vergelijken met wat er
> in 'lines'   zit. Die 'lines' zijn er dan enkel maar ter verificatie, of
> om ook al een idee te hebben welke buslijnen deze halte aandoen, voordat
> alle routerelaties zijn aangemaakt.

Blijkbaar is de structuur nog niet geheel duidelijk:

* basisrelatie voor elke buslijn
* die relatie heeft een aantal knooppunten onderweg (neem 4 in totaal: 2 
terminussen en 2 middenin de route) -- knooppunten die niet speciaal getagd 
worden
* laten we nu even stellen dat er geen variantes zijn, dan zijn dit dus 8 
relaties die in de basisrelatie moeten zitten (tussen elk knooppunt één voor 
heen en één voor terug)
* welke wegen gevolgd worden is eigenlijk maar in tweede instantie belangrijk, 
het belangrijkste is dat elk segmentrelatie een lijst van haltes heeft (de 
wegen gaan we toch ook nooit automatisch kunnen importeren)


Wat betekent dat dus voor een bushalte: die zal tot een aantal segmentrelaties 
behoren. Welke buslijnen daar dan stoppen kan je vinden door te kijken tot 
welke relatie die segmentrelatie toebehoort.


Moest je nu een variante hebben die op bepaalde uren van de dag niet aan 
bushalte X stopt, dan zijn er tussen de knooppunten in de heenrichting twee 
segmentrelaties: één die de bushalte X bevat, en één die de bushalte X niet 
bevat.


> > Eén relatie: bus 8
> > Met daarin een aantal andere relaties die op hun beurt dan de
> > to/from/via hebben die voor dat stuk op de bus of halte staan.
> 
> Ik krijg de indruk dat we over 3 niveaus van relaties aan het spreken zijn.
> 1 relatie voor bus 3308, meerdere relaties voor alle mogelijke varianten en
> richtingen, dewelke gebruik maken van relaties die 'strategische nodes' met
> elkaar verbinden.

Nee, ik heb het over twee niveaus: basisrelatie voor elke buslijn, 
segmentrelaties voor de routes (al is het eerder lijst van haltes).

Als tussen X en Y in de heenrichting twee varianten zijn, dan zijn er twee 
segmentrelaties voor de heenrichting tussen X en Y. Het is aan de scheduler om 
de juiste van de twee te kiezen.

't Is dus niet zo dat er nog meer groeperingen zijn.


Misschien dat er eens een voorbeeld in OSM moet worden gezet om het te 
verduidelijken :-)

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Jo
Op 14 oktober 2010 11:59 schreef Ben Laenen  het
volgende:

> 2010/10/14 Ivo De Broeck :
> > Eindelijk komen we nu een stapje vooruit. Voor de parent-relaties zouden
> we
> > dan ref=8 en name=stadsbus en ref=8 en name=nachtbus kunnen hebben (beide
> > bestaan).
>
> name=stadbus of nachtbus zou ik niet doen, dat is ook niet echt de
> naam van de buslijn. Wederom, andere tags kunnen gebruikt worden
> hiervoor. Als het verschil tussen bv een stadsbus en een streekbus wel
> duidelijk is natuurlijk, sommige streekbussen hebben nl. de functie
> van een stadsbus eens ze binnen de stadsagglomeratie zijn.
>
> Wat de nachtbus betreft: heeft die geen ref=N8 ipv ref=8?
>

Alleszins niet hier in het Leuvense.

>
> Nog om mee rekening te houden: Brussel heeft ook een avondnet, wat wil
> zeggen dat de buslijnen anders zijn na 22u.
>

Aan zee zijn er ook avondlijnen tijdens de zomermaanden, als 'k me niet
vergis.

>
>
> > Vraag blijft nog altijd dan de to en from (1 of 2 relaties) en het
> probleem
> > van de bus_stops (waar de ene richting een iets andere route volgt dan de
> > andere richting).
>
> Bij het geval parentrelatie + stukjes routerelaties, dan komen de
> haltes in de laatste te zitten. Een routerelatie in dit geval is
> slechts enkelrichting, dus tussen twee knooppunten zullen gewoonlijk
> wel twee relaties zitten voor beide richtingen. De richting van elke
> routerelatie kan dan wel bepaald worden met forward/backward roles.
>

Wel, de haltes in de segmenten steken, lijkt me problematisch om 2 redenen:
ten eerste doen snelbussen niet alle haltes aan en ten tweede is het
interessant om op het niveau van de haltes te kunnen zien door welke
route(relatie)s ze gebruikt worden. (om dit dan te vergelijken met wat er in
 'lines'   zit. Die 'lines' zijn er dan enkel maar ter verificatie, of om
ook al een idee te hebben welke buslijnen deze halte aandoen, voordat alle
routerelaties zijn aangemaakt.

>
> Maar we moeten er dus wel van afstappen dat je een routeplanner of
> iets dergelijks kan maken met enkel de OSM-data. Je hebt de schedule
> ook nodig. Pas dan weet je welke stukjes routerelatie op mekaar volgen
> op welk moment. Je kan een slimme gok doen, maar garantie dat bvb. het
> laatste stuk waar je naartoe moet gereden wordt op dat moment heb je
> met enkel OSM-data niet.
>
> Willen we dit dus echt bruikbaar maken, zijn we gedoemd om een
> nevenproject op te zetten :-)
>

Dat is altijd het uitgangspunt geweest. OSM levert de routes, de haltes en
hoe de haltes verbonden zijn met elkaar en de echte eindpunten van de
reisweg van de reiziger. Een ander project houdt de 'schedules'  bij. Dat is
informatie van een totaal andere orde, die op geen enkele wijze past in  de
datastructuur van OSM.

>
> > Misschien moeten we (voor de duidelijkheid) bij een parent-relatie het
> veld
> > direction bijvoegen forward/backward ? Dat betekent dat bus 8 forward
> wordt
> > from Bertem to Bierbeek en bus 8 backward als from Bierbeek to Bertem
> (dus 2
> > aparte relaties?)
>
> Waarom zou je de parentrelatie ook nog eens opsplitsen? Een volledige
> buslijn zit in dit geval onder één paraplu, inclusief al haar
> variantes.
>
> Eén relatie: bus 8
> Met daarin een aantal andere relaties die op hun beurt dan de
> to/from/via hebben die voor dat stuk op de bus of halte staan.
>

Ik krijg de indruk dat we over 3 niveaus van relaties aan het spreken zijn.
1 relatie voor bus 3308, meerdere relaties voor alle mogelijke varianten en
richtingen, dewelke gebruik maken van relaties die 'strategische nodes' met
elkaar verbinden.

Nu zou 'k, in het geval van een simpele verkorte reisweg, echter geen
variante aanmaken,. Enkel als de reisweg daadwerkelijk verschilt, zou 'k een
variante voorzien, anders is het eind zoek... Uiteraard is het einde van
zo'n verkorte reisweg dan ook zo'n strategische node. In ons voorbeeld van
bus 3308 is de halte Bierbeek Bremt, dus zo'n strategische node, aangezien
sommige bussen die als eindpunt hebben. Voor bus 3304/3305 is Heverlee
Kazerne zo'n node/knooppunt. Daar rijden de bussen tijdens het weekeinde een
blokje om, om weer in de juiste richting te staan voor de volgende rit.
Misschien moeten we die er ook maar 's bijnemen als we voorbeelden willen
uitwerken.

Nog een opmerking omdat ik er nu aan denk wat variantes betreft: we
> moeten ook eens nadenken over hoe we (het in Vlaanderen verdwenen,
> maar in Brussel nog bestaande) geval van doorstreepte nummers moeten
> behandelen. Bus 15 met streep door is een verkorte versie van bus 15.
> Is bus 15 barré dan een variante of een andere buslijn dan bus 15?
>

Aangezien  die grotendeels dezelfde reisweg volgen, zou 'k zeggen onder
dezelfde 'superrelatie'.

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


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Ben Laenen
2010/10/14 Ivo De Broeck :
> Eindelijk komen we nu een stapje vooruit. Voor de parent-relaties zouden we
> dan ref=8 en name=stadsbus en ref=8 en name=nachtbus kunnen hebben (beide
> bestaan).

name=stadbus of nachtbus zou ik niet doen, dat is ook niet echt de
naam van de buslijn. Wederom, andere tags kunnen gebruikt worden
hiervoor. Als het verschil tussen bv een stadsbus en een streekbus wel
duidelijk is natuurlijk, sommige streekbussen hebben nl. de functie
van een stadsbus eens ze binnen de stadsagglomeratie zijn.

Wat de nachtbus betreft: heeft die geen ref=N8 ipv ref=8?

Nog om mee rekening te houden: Brussel heeft ook een avondnet, wat wil
zeggen dat de buslijnen anders zijn na 22u.


> Vraag blijft nog altijd dan de to en from (1 of 2 relaties) en het probleem
> van de bus_stops (waar de ene richting een iets andere route volgt dan de
> andere richting).

Bij het geval parentrelatie + stukjes routerelaties, dan komen de
haltes in de laatste te zitten. Een routerelatie in dit geval is
slechts enkelrichting, dus tussen twee knooppunten zullen gewoonlijk
wel twee relaties zitten voor beide richtingen. De richting van elke
routerelatie kan dan wel bepaald worden met forward/backward roles.

Maar we moeten er dus wel van afstappen dat je een routeplanner of
iets dergelijks kan maken met enkel de OSM-data. Je hebt de schedule
ook nodig. Pas dan weet je welke stukjes routerelatie op mekaar volgen
op welk moment. Je kan een slimme gok doen, maar garantie dat bvb. het
laatste stuk waar je naartoe moet gereden wordt op dat moment heb je
met enkel OSM-data niet.

Willen we dit dus echt bruikbaar maken, zijn we gedoemd om een
nevenproject op te zetten :-)

> Misschien moeten we (voor de duidelijkheid) bij een parent-relatie het veld
> direction bijvoegen forward/backward ? Dat betekent dat bus 8 forward wordt
> from Bertem to Bierbeek en bus 8 backward als from Bierbeek to Bertem (dus 2
> aparte relaties?)

Waarom zou je de parentrelatie ook nog eens opsplitsen? Een volledige
buslijn zit in dit geval onder één paraplu, inclusief al haar
variantes.

Eén relatie: bus 8
Met daarin een aantal andere relaties die op hun beurt dan de
to/from/via hebben die voor dat stuk op de bus of halte staan.


Nog een opmerking omdat ik er nu aan denk wat variantes betreft: we
moeten ook eens nadenken over hoe we (het in Vlaanderen verdwenen,
maar in Brussel nog bestaande) geval van doorstreepte nummers moeten
behandelen. Bus 15 met streep door is een verkorte versie van bus 15.
Is bus 15 barré dan een variante of een andere buslijn dan bus 15?

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-14 Thread Ivo De Broeck
Akkoord, alleen willen we ook weten of het over een nachtbus of reguliere
bus gaat. De operator zou ik eruit laten (die staat al in een apart veld).
Korter (en duidelijker misschien) zou zijn 'Nachtbus 8 (to) Bierbeek'. Het
intern nummer 3008 in ref???

Op 14 oktober 2010 09:33 schreef Jo  het volgende:

> Ik begrijp, eerlijk gezegd, niet waarom de name stadsbus e.d. moet zijn.
> Waarom mag dat geen duidelijke beschrijving zijn van welke bus het is en van
> waar naar waar dat hij rijdt?
>
> De Lijn 3008 Bertem - Leuven - Lovenjoel - Bierbeek Bremt - Bierbeek De
> Borre
> en terug:
> De Lijn 3008 Bierbeek De Borre - Bierbeek Bremt - Lovenjoel - Leuven -
> Bertem
>
>
> Dat eerste cijfer is een intern nummer dat elke buslijn van De Lijn op
> unieke wijze beschrijft. Die nummers kunnen we achterhalen op de displays
> die aan de busterminals hangen, zodat de chauffeurs weten of ze mogen
> vertrekken.
>
> Jo
>
> Op 14 oktober 2010 09:03 schreef Ivo De Broeck het 
> volgende:
>
> Eindelijk komen we nu een stapje vooruit. Voor de parent-relaties zouden we
>> dan ref=8 en name=stadsbus en ref=8 en name=nachtbus kunnen hebben (beide
>> bestaan).
>> Vraag blijft nog altijd dan de to en from (1 of 2 relaties) en het
>> probleem van de bus_stops (waar de ene richting een iets andere route volgt
>> dan de andere richting).
>> Misschien moeten we (voor de duidelijkheid) bij een parent-relatie het
>> veld direction bijvoegen forward/backward ? Dat betekent dat bus 8 forward
>> wordt from Bertem to Bierbeek en bus 8 backward als from Bierbeek to Bertem
>> (dus 2 aparte relaties?)
>>
>>
>> Op 13 oktober 2010 23:15 schreef Jo  het volgende:
>>
>>>
>>>
>>> Op 13 oktober 2010 20:13 schreef Ben Laenen  het
>>> volgende:
>>>
>>> Ivo De Broeck wrote:
 > Dus als ik het goed begrijp is die to, from en via nu wel nuttig, maar
 > onbruikbaar bij 1 relatie. Of wordt het dan from Bertem to Bertem via
 > Leuven, Bremt en Bierbeek ?
 >
 > Graag had ik ook de mening vernomen van mensen die busroutes (proberen
 > te) taggen en hun ervaringen laten weten. Ik vermoed dat de 2 relaties
 een
 > algemene tendens is.

 Een tendens waar in België alleszins nog niet veel van te merken valt?

>>>
>>> Totnogtoe hebben we die bus relations aangemaakt zoals we dat deden voor
>>> de cycle route relations. Dat lijkt me ondertussen niet meer de beste wijze.
>>> De reden waarom we die wikipagina willen aanpassen is niet om te beschrijven
>>> hoe het tot nu toe gedaan werd, maar wel om tot een goede oplossing te komen
>>> voor de toekomst. Er kruipt veel tijd in om het allemaal te
>>> beschrijven/mappen en daarom zouden we het liefst van de eerste keer (zo)
>>> goed (mogelijk) doen.
>>>
>>>
 > In OSM werd voor busroutes voorgesteld bij 'name' snelbus, stadsbus,
 bus in
 > te vullen?

 Dat heb ik toch niet gezegd. Vroeger werd gewoon iets als "name=Centraal
 Station - Luchthaven" getagd. Over snelbussen en dergelijke was nog niks
 te
 vinden.

>>>
>>> Dat lijkt mij de beste manier, maar het nummer moet er ook voor. Stom dat
>>> die informatie dan zowel in ref als in name zit, maar je die nummers zijn
>>> daar belangrijk genoeg voor.
>>>
>>> De reden waarom aan aantal mensen in het verleden (en nu nog) twee
 relaties
 wou is omdat ze in de war geraken van de forward/backward roles die
 nodig zijn
 in één relatie. Het enige nut hiervan was dus dat ze het makkelijker
 zouden
 maken voor de mapper. Alleen kan je met één relatie met forward/backward
 net
 zo veel kwijt als met twee zonder roles en dus gaat mijn voorkeur hier
 uit
 naar één relatie ("het is makkelijker te mappen" valt bij mij onder
 dezelfde
 categorie als "mappen om het mooi te laten renderen"). Daarentegen ga je
 met
 twee relaties problemen introduceren die je met één relatie niet hebt
 (cirkellijnen?) en los je dingen niet op die ook bij één relatie een
 probleem
 vormen (lussen?).

 Tot daar de discussie van één/twee relaties.

>>>
>>> Ik kan op beide manieren mappen en, eerlijk gezegd vind 'k 1 relatie
>>> gemakkelijker. Als je echter wilt 'exact'  wil kunnen aangeven welke
>>> wegsegmenten een bus gebruikt, heeft het geen zin om beide richtingen in 1
>>> relatie te stoppen. Ik denk hierbij aan het stukje Tiensevest over het
>>> Martelarenplein dat door sommige bussen 2x gebruikt, eenmaal om van de
>>> Maria-Theresiastraat naar de terminal te gaan en nadien om van de terminal
>>> naar de Bondgenotenlaan te gaan. Dezelfde situatie bestaat op een rond punt
>>> in Diest waar een kwart vh ronde punt 2x gebruikt wordt door de bussen die
>>> van de Leuvensesteenweg rechts de ring oprijden, maar eerst nog een halte
>>> links op het ronde punt bedienen.
>>>
>>> De reden waarom we het voordien met 1 relatie deden, is dat er geen
>>> volgorde aan de segmenten kon worden meegegeven.
>>>
>>>

 Maar nu hebben we ook eens kunnen kijken naa

Re: [OSM-talk-be] busroutes

2010-10-14 Thread Ivo De Broeck
Eindelijk komen we nu een stapje vooruit. Voor de parent-relaties zouden we
dan ref=8 en name=stadsbus en ref=8 en name=nachtbus kunnen hebben (beide
bestaan).
Vraag blijft nog altijd dan de to en from (1 of 2 relaties) en het probleem
van de bus_stops (waar de ene richting een iets andere route volgt dan de
andere richting).
Misschien moeten we (voor de duidelijkheid) bij een parent-relatie het veld
direction bijvoegen forward/backward ? Dat betekent dat bus 8 forward wordt
from Bertem to Bierbeek en bus 8 backward als from Bierbeek to Bertem (dus 2
aparte relaties?)


Op 13 oktober 2010 23:15 schreef Jo  het volgende:

>
>
> Op 13 oktober 2010 20:13 schreef Ben Laenen  het
> volgende:
>
> Ivo De Broeck wrote:
>> > Dus als ik het goed begrijp is die to, from en via nu wel nuttig, maar
>> > onbruikbaar bij 1 relatie. Of wordt het dan from Bertem to Bertem via
>> > Leuven, Bremt en Bierbeek ?
>> >
>> > Graag had ik ook de mening vernomen van mensen die busroutes (proberen
>> > te) taggen en hun ervaringen laten weten. Ik vermoed dat de 2 relaties
>> een
>> > algemene tendens is.
>>
>> Een tendens waar in België alleszins nog niet veel van te merken valt?
>>
>
> Totnogtoe hebben we die bus relations aangemaakt zoals we dat deden voor de
> cycle route relations. Dat lijkt me ondertussen niet meer de beste wijze. De
> reden waarom we die wikipagina willen aanpassen is niet om te beschrijven
> hoe het tot nu toe gedaan werd, maar wel om tot een goede oplossing te komen
> voor de toekomst. Er kruipt veel tijd in om het allemaal te
> beschrijven/mappen en daarom zouden we het liefst van de eerste keer (zo)
> goed (mogelijk) doen.
>
>
>> > In OSM werd voor busroutes voorgesteld bij 'name' snelbus, stadsbus, bus
>> in
>> > te vullen?
>>
>> Dat heb ik toch niet gezegd. Vroeger werd gewoon iets als "name=Centraal
>> Station - Luchthaven" getagd. Over snelbussen en dergelijke was nog niks
>> te
>> vinden.
>>
>
> Dat lijkt mij de beste manier, maar het nummer moet er ook voor. Stom dat
> die informatie dan zowel in ref als in name zit, maar je die nummers zijn
> daar belangrijk genoeg voor.
>
> De reden waarom aan aantal mensen in het verleden (en nu nog) twee relaties
>> wou is omdat ze in de war geraken van de forward/backward roles die nodig
>> zijn
>> in één relatie. Het enige nut hiervan was dus dat ze het makkelijker
>> zouden
>> maken voor de mapper. Alleen kan je met één relatie met forward/backward
>> net
>> zo veel kwijt als met twee zonder roles en dus gaat mijn voorkeur hier uit
>> naar één relatie ("het is makkelijker te mappen" valt bij mij onder
>> dezelfde
>> categorie als "mappen om het mooi te laten renderen"). Daarentegen ga je
>> met
>> twee relaties problemen introduceren die je met één relatie niet hebt
>> (cirkellijnen?) en los je dingen niet op die ook bij één relatie een
>> probleem
>> vormen (lussen?).
>>
>> Tot daar de discussie van één/twee relaties.
>>
>
> Ik kan op beide manieren mappen en, eerlijk gezegd vind 'k 1 relatie
> gemakkelijker. Als je echter wilt 'exact'  wil kunnen aangeven welke
> wegsegmenten een bus gebruikt, heeft het geen zin om beide richtingen in 1
> relatie te stoppen. Ik denk hierbij aan het stukje Tiensevest over het
> Martelarenplein dat door sommige bussen 2x gebruikt, eenmaal om van de
> Maria-Theresiastraat naar de terminal te gaan en nadien om van de terminal
> naar de Bondgenotenlaan te gaan. Dezelfde situatie bestaat op een rond punt
> in Diest waar een kwart vh ronde punt 2x gebruikt wordt door de bussen die
> van de Leuvensesteenweg rechts de ring oprijden, maar eerst nog een halte
> links op het ronde punt bedienen.
>
> De reden waarom we het voordien met 1 relatie deden, is dat er geen
> volgorde aan de segmenten kon worden meegegeven.
>
>
>>
>> Maar nu hebben we ook eens kunnen kijken naar de data zoals die door De
>> Lijn
>> wordt bijgehouden, en zo leren we dat ze werken met knooppunten
>> (belangrijke
>> haltes) waartussen de lijnen rijden. Een buslijn bestaat in dat geval uit
>> een
>> lijst van routes (en een route is een lijst haltes) tussen knooppunten.
>> Een
>> schedule zorgt er dan voor dat de stukjes aan mekaar aansluiten en dat je
>> bvb.
>> in het weekend via route A gaat en in de week via route B.
>>
>> Leuk, dit houdt steek. Een basisrelatie voor de buslijn die een aantal
>> kindrelaties omvat voor elk stukje.
>>
>
> Hmm, mijn experiment met child relations houdt dan toch steek. Ik haat het
> om informatie te dupliceren, dus ik ben zeker voorstander om het zo aan te
> pakken. De tool in JOSM om public transport relations aan te maken,
> ondersteunt dat echter niet. En zetten we de haltes op die
> gemeenschappelijke stukken/child relations dan wel mee in de relaties voor
> de uiteindelijke lijnen? Child relations maken het allemaal wat complexer
> voor de mapper, maar maken de data een stuk interessanter om mee te werken,
> achteraf. Zowel voor routing, als wat betreft onderhoud.
>
> Ik zou graag zien dat er met child relations gewerkt wordt

Re: [OSM-talk-be] busroutes

2010-10-13 Thread Jo
Op 13 oktober 2010 20:13 schreef Ben Laenen  het
volgende:

> Ivo De Broeck wrote:
> > Dus als ik het goed begrijp is die to, from en via nu wel nuttig, maar
> > onbruikbaar bij 1 relatie. Of wordt het dan from Bertem to Bertem via
> > Leuven, Bremt en Bierbeek ?
> >
> > Graag had ik ook de mening vernomen van mensen die busroutes (proberen
> > te) taggen en hun ervaringen laten weten. Ik vermoed dat de 2 relaties
> een
> > algemene tendens is.
>
> Een tendens waar in België alleszins nog niet veel van te merken valt?
>

Totnogtoe hebben we die bus relations aangemaakt zoals we dat deden voor de
cycle route relations. Dat lijkt me ondertussen niet meer de beste wijze. De
reden waarom we die wikipagina willen aanpassen is niet om te beschrijven
hoe het tot nu toe gedaan werd, maar wel om tot een goede oplossing te komen
voor de toekomst. Er kruipt veel tijd in om het allemaal te
beschrijven/mappen en daarom zouden we het liefst van de eerste keer (zo)
goed (mogelijk) doen.


> > In OSM werd voor busroutes voorgesteld bij 'name' snelbus, stadsbus, bus
> in
> > te vullen?
>
> Dat heb ik toch niet gezegd. Vroeger werd gewoon iets als "name=Centraal
> Station - Luchthaven" getagd. Over snelbussen en dergelijke was nog niks te
> vinden.
>

Dat lijkt mij de beste manier, maar het nummer moet er ook voor. Stom dat
die informatie dan zowel in ref als in name zit, maar je die nummers zijn
daar belangrijk genoeg voor.

De reden waarom aan aantal mensen in het verleden (en nu nog) twee relaties
> wou is omdat ze in de war geraken van de forward/backward roles die nodig
> zijn
> in één relatie. Het enige nut hiervan was dus dat ze het makkelijker zouden
> maken voor de mapper. Alleen kan je met één relatie met forward/backward
> net
> zo veel kwijt als met twee zonder roles en dus gaat mijn voorkeur hier uit
> naar één relatie ("het is makkelijker te mappen" valt bij mij onder
> dezelfde
> categorie als "mappen om het mooi te laten renderen"). Daarentegen ga je
> met
> twee relaties problemen introduceren die je met één relatie niet hebt
> (cirkellijnen?) en los je dingen niet op die ook bij één relatie een
> probleem
> vormen (lussen?).
>
> Tot daar de discussie van één/twee relaties.
>

Ik kan op beide manieren mappen en, eerlijk gezegd vind 'k 1 relatie
gemakkelijker. Als je echter wilt 'exact'  wil kunnen aangeven welke
wegsegmenten een bus gebruikt, heeft het geen zin om beide richtingen in 1
relatie te stoppen. Ik denk hierbij aan het stukje Tiensevest over het
Martelarenplein dat door sommige bussen 2x gebruikt, eenmaal om van de
Maria-Theresiastraat naar de terminal te gaan en nadien om van de terminal
naar de Bondgenotenlaan te gaan. Dezelfde situatie bestaat op een rond punt
in Diest waar een kwart vh ronde punt 2x gebruikt wordt door de bussen die
van de Leuvensesteenweg rechts de ring oprijden, maar eerst nog een halte
links op het ronde punt bedienen.

De reden waarom we het voordien met 1 relatie deden, is dat er geen volgorde
aan de segmenten kon worden meegegeven.


>
> Maar nu hebben we ook eens kunnen kijken naar de data zoals die door De
> Lijn
> wordt bijgehouden, en zo leren we dat ze werken met knooppunten
> (belangrijke
> haltes) waartussen de lijnen rijden. Een buslijn bestaat in dat geval uit
> een
> lijst van routes (en een route is een lijst haltes) tussen knooppunten. Een
> schedule zorgt er dan voor dat de stukjes aan mekaar aansluiten en dat je
> bvb.
> in het weekend via route A gaat en in de week via route B.
>
> Leuk, dit houdt steek. Een basisrelatie voor de buslijn die een aantal
> kindrelaties omvat voor elk stukje.
>

Hmm, mijn experiment met child relations houdt dan toch steek. Ik haat het
om informatie te dupliceren, dus ik ben zeker voorstander om het zo aan te
pakken. De tool in JOSM om public transport relations aan te maken,
ondersteunt dat echter niet. En zetten we de haltes op die
gemeenschappelijke stukken/child relations dan wel mee in de relaties voor
de uiteindelijke lijnen? Child relations maken het allemaal wat complexer
voor de mapper, maar maken de data een stuk interessanter om mee te werken,
achteraf. Zowel voor routing, als wat betreft onderhoud.

Ik zou graag zien dat er met child relations gewerkt wordt, maar dan zouden
we dat er toch ook op globaal vlak door moeten krijgen. Zodat heel OSM het
op die manier doet.


> Variantes worden dan ook een stuk overzichtelijker: stel dat je lijn op
> drie
> plekken een variante heeft, dan kan je ofwel 8 relaties aanmaken tussen de
> twee terminussen (maal 2 voor elke richting), en dan heb je wegen waar 16
> keer
> een relatie voor buslijn X op staat. Met knooppunten tussen de variante
> routes
> ga je er niet meer dan 4 hebben op een weg (met de voorwaarde dus dat er
> ook
> knooppunten liggen tussen waar de variantes genomen worden).
>
> Het totaal aantal relaties voor routes zonder varianten stijgt natuurlijk
> spectaculair.
>
> Minder leuk natuurlijk: we kennen helemaal niet de knooppunten die De Lijn
> gebruikt, en we

Re: [OSM-talk-be] busroutes

2010-10-13 Thread Ben Laenen
Ivo De Broeck wrote:
> Dus als ik het goed begrijp is die to, from en via nu wel nuttig, maar
> onbruikbaar bij 1 relatie. Of wordt het dan from Bertem to Bertem via
> Leuven, Bremt en Bierbeek ?
> 
> Graag had ik ook de mening vernomen van mensen die busroutes (proberen
> te) taggen en hun ervaringen laten weten. Ik vermoed dat de 2 relaties een
> algemene tendens is.

Een tendens waar in België alleszins nog niet veel van te merken valt?

> In OSM werd voor busroutes voorgesteld bij 'name' snelbus, stadsbus, bus in
> te vullen?

Dat heb ik toch niet gezegd. Vroeger werd gewoon iets als "name=Centraal 
Station - Luchthaven" getagd. Over snelbussen en dergelijke was nog niks te 
vinden.

> Ik probeer dat terug te vinden in de wiki. De tabel werd
> trouwens gewoon uit de wiki gekopieerd (ook met de color en text-color ipv
> colour).
> 
> Kunnen we stap voor stap werken:
> 1) akkoord over (minstens) 2 relaties (heen en terug) aan te bevelen

Ik kan me hier maar blijven herhalen, maar desondanks een nieuwe poging. Er 
lopen hier nu namelijk meerdere discussies door mekaar.

De reden waarom aan aantal mensen in het verleden (en nu nog) twee relaties 
wou is omdat ze in de war geraken van de forward/backward roles die nodig zijn 
in één relatie. Het enige nut hiervan was dus dat ze het makkelijker zouden 
maken voor de mapper. Alleen kan je met één relatie met forward/backward net 
zo veel kwijt als met twee zonder roles en dus gaat mijn voorkeur hier uit 
naar één relatie ("het is makkelijker te mappen" valt bij mij onder dezelfde 
categorie als "mappen om het mooi te laten renderen"). Daarentegen ga je met 
twee relaties problemen introduceren die je met één relatie niet hebt 
(cirkellijnen?) en los je dingen niet op die ook bij één relatie een probleem 
vormen (lussen?).

Tot daar de discussie van één/twee relaties.


Maar nu hebben we ook eens kunnen kijken naar de data zoals die door De Lijn 
wordt bijgehouden, en zo leren we dat ze werken met knooppunten (belangrijke 
haltes) waartussen de lijnen rijden. Een buslijn bestaat in dat geval uit een 
lijst van routes (en een route is een lijst haltes) tussen knooppunten. Een 
schedule zorgt er dan voor dat de stukjes aan mekaar aansluiten en dat je bvb. 
in het weekend via route A gaat en in de week via route B.

Leuk, dit houdt steek. Een basisrelatie voor de buslijn die een aantal 
kindrelaties omvat voor elk stukje.

Variantes worden dan ook een stuk overzichtelijker: stel dat je lijn op drie 
plekken een variante heeft, dan kan je ofwel 8 relaties aanmaken tussen de 
twee terminussen (maal 2 voor elke richting), en dan heb je wegen waar 16 keer 
een relatie voor buslijn X op staat. Met knooppunten tussen de variante routes 
ga je er niet meer dan 4 hebben op een weg (met de voorwaarde dus dat er ook 
knooppunten liggen tussen waar de variantes genomen worden).

Het totaal aantal relaties voor routes zonder varianten stijgt natuurlijk 
spectaculair.

Minder leuk natuurlijk: we kennen helemaal niet de knooppunten die De Lijn 
gebruikt, en we zullen dus een beetje zelf moeten kiezen waar ze zijn zich 
bevinden. En dan zullen enkele slimme mensen hier wel enkel beide terminussen 
als zo'n knooppunt maken. So be it, alleen is onze structuur dan duizend keer 
beter om met alle soorten speciale situaties rekening te houden zoals lussen 
en variantes, en zijn we ook voorbereid voor het geval we ooit wél de data van 
De Lijn krijgen.



tl;dr:

* één relatie = twee relaties = even goed/slecht
* basisrelatie per lijn + kindrelaties voor routes tussen knooppunten = veel 
dichter bij datastructuur De Lijn



> 2) de velden to from en via
>
> 3) het facultatief gebruik van text_colo(u)r en colo(u)r en de schrijfwijze
> (persoonlijk zie ik liever color omdat dit ook html-commando-taal is)
> Als we het daar al over eens kunnen worden, zijn we al een grote stap
> voorwaarts.

Hier is geen discussie mogelijk: het is colour met een "u". Dat er op de wiki 
nog zonder "u" stond komt waarschijnlijk omdat ik(?) het daar jaren terug 
vlug-vlug heb neergezet om iets te hebben, en er achteraf niet meer naar 
gekeken heb.

OSM-tags zijn in Brits Engels, colour dus ook. En zoals vermeld is er al eens 
een bot doorheen de data gefietst die alle "color" tags naar "colour" heeft 
omgezet.

Andere opmerking die er ook echt bij moet is dat text_colour slechts zeer 
zelden moet gebruikt worden voor De Lijn (ik ken enkel tram 15 (groen op wit) 
en 11 (rood op wit) in Antwerpen, en deze hadden eigenlijk ook niet meer 
bestaan moest De Lijn haar zin gedaan hebben, zo was tram 15 al eens enkel 
beige, en 11 iets blauw/groenachtig, maar ze kregen tegenwind van reizigers 
die tram 15 met tram 3 (geel) verwarden, en tram 11 met tram 10 (groen); 
reizigers stappen verkeerde tram op, zijn kwaad tegen chauffeur, vakbond wil 
en krijgt oude kleuren terug -- tot zover de petite histoire :-) ).

Ben

___
Talk-be mailing list
Talk-be@openstreetmap.org
http://

Re: [OSM-talk-be] busroutes

2010-10-13 Thread Ivo De Broeck
oeps sorry, talk-be vergeten.

Op 13 oktober 2010 18:22 schreef Ben Laenen  het
volgende:

> (antwoord van Ivo was niet naar mailinglijst, dus lees ook de quotes)
>
> Ivo De Broeck wrote:
> > Er staat wel meer op bussen en bushalten. Bij mijn bushalte staat "8
> Bertem
> > via Egenhoven" en "380 Leuven - Gasthuisberg". Aan de overkant totaal
> > andere zaken ;-)
> >
> > Gebruik eens Potlatch en JOSM met plugin openbaar vervoer, misschien
> > begrijp je dan beter dit voorstel. Als je "8" als een ref gebruikt en je
> > steekt alle mogelijke trips van alle bussen die met "8" rondrijden in 1
> > relatie kan dat werken (alhoewel er wel nog veel achtten zijn).
> >
> > Hier gaat het om een relatie over een trip van Bertem naar Bierbeek (via
> > bremt), das iets totaal anders dan de relatie van dennacht. Deze
> informatie
> > in name steken lijkt geen oplossing, maar intussen wordt meer en meer de
> > ref gebruikt.
> >
> > In plaats van te stellen wat niet mag, misschien kan jij voorstellen in
> > welke tag dit wel thuishoort? Ik wil wel de informatie 'bus 8 Bierbeek
> via
> > bremt" ergens duidelijk terugvinden en ook gerenderd worden. Voorlopig
> > werkt to/from/via niet echt.
>
> Dus is je enige probleem dat het nergens gerenderd wordt? Moet je eens
> googelen op "don't tag for the renderer"... From/to/via werkt perfect voor
> deze informatie. De voorbije jaren stond het simpelweg in de name=* tag.
>
> Op deze manier kan je de persoon die de rendering maakt laten kiezen wat
> hij
> allemaal wel of niet toont. Op lagere zooms is dat dan bvb. enkel het
> buslijnnummer bij een halte. Op de hoogste zoom kan er dan ook de
> bestemming
> en via bijstaan. Vergelijk het met de bussen waar opzij en achteraan ook
> enkel
> het nummer zichtbaar is, maar vooraan de bus staat dan wel de bestemming.
>
> In OSM maken we een databank, en geen kaartjes (die zijn maar een mooi
> neveneffect :-) ), en het verschil zit hem er dus in dat we niet gaan
> taggen
> zodat we perfect de rendering krijgen die we willen, maar wel de data zo
> correct mogelijk invoeren.
>
>
> > Graag had ik ook de mening vernomen van mensen die busroutes (proberen
> te)
> >  taggen en hun ervaringen laten weten.
>
> Ben
>


Dus als ik het goed begrijp is die to, from en via nu wel nuttig, maar
onbruikbaar bij 1 relatie. Of wordt het dan from Bertem to Bertem via
Leuven, Bremt en Bierbeek ?

Graag had ik ook de mening vernomen van mensen die busroutes (proberen
te) taggen en hun ervaringen laten weten. Ik vermoed dat de 2 relaties een
algemene tendens is.

In OSM werd voor busroutes voorgesteld bij 'name' snelbus, stadsbus, bus in
te vullen? Ik probeer dat terug te vinden in de wiki. De tabel werd trouwens
gewoon uit de wiki gekopieerd (ook met de color en text-color ipv colour).

Kunnen we stap voor stap werken:
1) akkoord over (minstens) 2 relaties (heen en terug) aan te bevelen
2) de velden to from en via
3) het facultatief gebruik van text_colo(u)r en colo(u)r en de schrijfwijze
(persoonlijk zie ik liever color omdat dit ook html-commando-taal is)
Als we het daar al over eens kunnen worden, zijn we al een grote stap
voorwaarts.
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-13 Thread Ben Laenen
(antwoord van Ivo was niet naar mailinglijst, dus lees ook de quotes)

Ivo De Broeck wrote:
> Er staat wel meer op bussen en bushalten. Bij mijn bushalte staat "8 Bertem
> via Egenhoven" en "380 Leuven - Gasthuisberg". Aan de overkant totaal
> andere zaken ;-)
> 
> Gebruik eens Potlatch en JOSM met plugin openbaar vervoer, misschien
> begrijp je dan beter dit voorstel. Als je "8" als een ref gebruikt en je
> steekt alle mogelijke trips van alle bussen die met "8" rondrijden in 1
> relatie kan dat werken (alhoewel er wel nog veel achtten zijn).
> 
> Hier gaat het om een relatie over een trip van Bertem naar Bierbeek (via
> bremt), das iets totaal anders dan de relatie van dennacht. Deze informatie
> in name steken lijkt geen oplossing, maar intussen wordt meer en meer de
> ref gebruikt.
> 
> In plaats van te stellen wat niet mag, misschien kan jij voorstellen in
> welke tag dit wel thuishoort? Ik wil wel de informatie 'bus 8 Bierbeek via
> bremt" ergens duidelijk terugvinden en ook gerenderd worden. Voorlopig
> werkt to/from/via niet echt.

Dus is je enige probleem dat het nergens gerenderd wordt? Moet je eens 
googelen op "don't tag for the renderer"... From/to/via werkt perfect voor 
deze informatie. De voorbije jaren stond het simpelweg in de name=* tag.

Op deze manier kan je de persoon die de rendering maakt laten kiezen wat hij 
allemaal wel of niet toont. Op lagere zooms is dat dan bvb. enkel het 
buslijnnummer bij een halte. Op de hoogste zoom kan er dan ook de bestemming 
en via bijstaan. Vergelijk het met de bussen waar opzij en achteraan ook enkel 
het nummer zichtbaar is, maar vooraan de bus staat dan wel de bestemming.

In OSM maken we een databank, en geen kaartjes (die zijn maar een mooi 
neveneffect :-) ), en het verschil zit hem er dus in dat we niet gaan taggen 
zodat we perfect de rendering krijgen die we willen, maar wel de data zo 
correct mogelijk invoeren.


> Graag had ik ook de mening vernomen van mensen die busroutes (proberen te)
>  taggen en hun ervaringen laten weten.

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-13 Thread Ben Laenen
Ivo De Broeck wrote:
> nat_ref is een nationale referentie die oa de operator bevat en dus voor
> alle psv-lijnen zou kunnen gelden. Hoe die er juist moet uit zien, is nog
> niet bepaald. Zoiets als 'DL LEUVEN stadsbus 8' bv.

Dit snap ik al helemaal niet? nat_ref is te vergelijken met de snelwegen, 
zoals nat_ref=A1 voor de E19 tussen Brussel en Nederland.

nat_ref heeft m.a.w. enkel nut in grensoverschrijdende situaties waar een bus 
onder een ander lijnnummer bekend staat dan internationaal, of nationaal een 
ander lijnnummer dan lokaal. En zo'n gevallen ken ik helemaal niet.

Het gedoe van "DL Leuven stadsbus" heeft niks te zoeken in een ref.


> Je vergelijking met de E19 slaat mijn inziens nergens op. Wegen worden niet
> in routes Antwerpen-Brussel gegoten. Wandelwegen zijn (meestal) een
> gesloten lus, die in 1 relatie kunnen geplaatst. Busroutes zijn nu eenmaal
> van A naar B. Sta aan de juiste bushalte of je komt in A teecht als je in
> B moet zijn ;-)

Wel, bekijk de snelwegen dan nog eens goed, want ze bevatten allemaal een 
routerelatie voor hun A-nummer, en als ze er één hebben, ook voor hun E-nummer 
(ook al was ik er indertijd ook niet echt voor om deze refs als routerelatie 
te hebben, maar soit). En als je niet de juiste oprit neemt ga je ook niet in 
A maar in B zitten.

Punt is dat de ref nu eens één ding is waarover niet te discussiëren valt: het 
is het nummer van de bus- of tramlijn, en dat is het getalletje dat vooraan, 
opzij, en achteraan de bus staat, en op de tramhalteborden, en in de data van 
De Lijn onder public_identifier.

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-13 Thread Ivo De Broeck
nat_ref is een nationale referentie die oa de operator bevat en dus voor
alle psv-lijnen zou kunnen gelden. Hoe die er juist moet uit zien, is nog
niet bepaald. Zoiets als 'DL LEUVEN stadsbus 8' bv.

Je vergelijking met de E19 slaat mijn inziens nergens op. Wegen worden niet
in routes Antwerpen-Brussel gegoten. Wandelwegen zijn (meestal) een gesloten
lus, die in 1 relatie kunnen geplaatst. Busroutes zijn nu eenmaal van A naar
B. Sta aan de juiste bushalte of je komt in A teecht als je in B moet zijn
;-)

Op 13 oktober 2010 11:55 schreef Ben Laenen  het
volgende:

> 2010/10/13 Ivo De Broeck :
> > Sommige bus_halten bevatten naast de naam, het refertenummer, het
> > zone-nummer ook een veld "STAD" op blauwe achtergrond. Weet iemand de
> > betekenis hiervan?
> > Ondertussen is
> > de
> http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines
> > opgeschoond. Het voorstel houd ook reeds rekening met "De Lijn"
> > (achtergrondkleur en tekstkleuren). Graag uw opmerkingen.
> > Vergeet ook de
> > pagina
> http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_stops
> > niet.
>
> Een ding dat ik al gezegd heb: de ref=* tag mag enkel het
> buslijnnummer bevatten, geen bestemming of wat dan ook om een
> onderscheid te maken met de terugweg. Want dit valt in dezelfde
> categorie als de ref=55* (met de asterisk) die een paar weken terug is
> vermeld op de mailinglijst. Het onderscheid kan je maken in de
> verschillende andere tags en dat is meer dan voldoende. Het heeft zo'n
> beetje weg als de ene helft van de E19 tussen Antwerpen en Brussel te
> taggen met "E19 Antwerpen" en de andere helft met "E19 Brussel".
>
> nat_ref: ik begrijp dat dat van de Oxomoapagina komt, maar wat is er
> het nut van? Ken je één voorbeeld in België waar er een aparte nat_ref
> is?
>
> Ik ben er ook niet van overtuigd dat wat internationaal begrepen wordt
> onder de "on_demand" dat dat overeenkomt met onze belbussen.
>
> De bus- en servicetags moeten nog eens goed bekeken worden want ik heb
> de indruk dat ze mekaar wat overlappen. Zegt bus=school niet meer iets
> over frequentie bv.?
>
> Ben
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-13 Thread Ben Laenen
2010/10/13 Ivo De Broeck :
> Sommige bus_halten bevatten naast de naam, het refertenummer, het
> zone-nummer ook een veld "STAD" op blauwe achtergrond. Weet iemand de
> betekenis hiervan?
> Ondertussen is
> de http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines
> opgeschoond. Het voorstel houd ook reeds rekening met "De Lijn"
> (achtergrondkleur en tekstkleuren). Graag uw opmerkingen.
> Vergeet ook de
> pagina http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_stops
> niet.

Een ding dat ik al gezegd heb: de ref=* tag mag enkel het
buslijnnummer bevatten, geen bestemming of wat dan ook om een
onderscheid te maken met de terugweg. Want dit valt in dezelfde
categorie als de ref=55* (met de asterisk) die een paar weken terug is
vermeld op de mailinglijst. Het onderscheid kan je maken in de
verschillende andere tags en dat is meer dan voldoende. Het heeft zo'n
beetje weg als de ene helft van de E19 tussen Antwerpen en Brussel te
taggen met "E19 Antwerpen" en de andere helft met "E19 Brussel".

nat_ref: ik begrijp dat dat van de Oxomoapagina komt, maar wat is er
het nut van? Ken je één voorbeeld in België waar er een aparte nat_ref
is?

Ik ben er ook niet van overtuigd dat wat internationaal begrepen wordt
onder de "on_demand" dat dat overeenkomt met onze belbussen.

De bus- en servicetags moeten nog eens goed bekeken worden want ik heb
de indruk dat ze mekaar wat overlappen. Zegt bus=school niet meer iets
over frequentie bv.?

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-13 Thread Ivo De Broeck
Sommige bus_halten bevatten naast de naam, het refertenummer, het
zone-nummer ook een veld "STAD" op blauwe achtergrond. Weet iemand de
betekenis hiervan?
Ondertussen is de
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_linesopgeschoond.
Het voorstel houd ook reeds rekening met "De Lijn"
(achtergrondkleur en tekstkleuren). Graag uw opmerkingen.
Vergeet ook de pagina
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_stopsniet.
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-12 Thread Ben Laenen
2010/10/10 Jo :
> Ivo, ik zou op de wikipagina beschrijven dat er een heen- en een terugroute
> gemapt wordt. Dat is de enige wijze waar een routeplanner iets aan heeft.
> Als mensen het dan toch met 1 route/buslijn blijven mappen, dan betekent dat
> weer werk voor iemand die wel weet waar hij mee bezig is, om ze te
> ontdubbelen.

> Ben, moeten we stemmen over 1 of 2 relaties/busroute? Of kunnen we ervan
> uitgaan dat iedereen inziet dat dat de correcte manier van werken is? Wie
> dat niet ziet, zou Oxomoa er 's op moeten nalezen. Die mensen hebben daar
> hard over nagedacht voordat ze dat document maakten.

Ja zeg, ieder mag zijn mening hebben, en over vele dingen heb ik al
mijn mening herzien. Alleen gebeurt dat dan wel door argumenten en
niet door een betoog zoals hierboven.

Als het allemaal zo zonneklaar is, laat dan zeker de waterval aan
argumenten op me los. Want op je geciteerde Oxomoapagina staat er ook
niets over het waarom het per se twee relaties moeten zijn i.p.v. één.


> De reden waarom 'k De Lijn had aangeschreven, was eigenlijk
> voornamelijk omdat 'k hun datamodel had willen zien. Ik vermoed namelijk dat
> we er zelfs met 2 relaties/lijn niet gaan komen.

Zie, hier komen we ergens: twee relaties zijn niet beter dan één (in
mijn opinie natuurlijk en voor redenen die je wel terugvindt in de
archieven van de mailinglijst), maar meerdere relaties kunnen wel een
verbetering geven. En dan gaat het over een aparte relatie voor alle
mogelijke routes tussen de "knooppunten" (die in places staan in de
data van De Lijn, i.e. de belangrijke stopplaatsen) van een buslijn.

En ja, in sommige gevallen kan dit gerust twee relaties vormen met een
heen- en een terugweg. Alleen is er nu geen enkele constraint meer op
het aantal stukken, en kan je gaan van één relatie voor een
cirkelvormige lijn naar zoveel je wil voor lijnen die alle soorten van
variantes heeft op elk uur van de dag. En dit past zich veel
makkelijker aan aan de vorm waarin je de data krijgt.


> Wat met verkorte ritten?
> Wat met ritten die soms een andere route volgen, afh. vd dag van de week. Ik
> denk bijv. aan lijn 630. Die het industrieterrein niet bedient tijdens het
> weekeinde en die dan een stukje expressweg volgt. Of dat voor die lijn
> belang heeft, is natuurlijk de vraag. Als je de 'schedule' erbij neemt, is
> het wel duidelijk welke haltes wel of niet bediend worden. Maar dat is nu
> net het stukje dat we niet kwijt kunnen in de OSM-database.

In de OSM-database komt inderdaad geen schedule en dus kunnen we enkel
maar elke halte waar een bus van een zekere buslijn stopt tot de
buslijnrelatie (of haar kindrelaties) zetten. Het probleem dat
bushalte X bv. in het weekend niet bediend wordt is een probleem dat
we in het kader van OSM niet moeten oplossen. We tonen dus enkel alle
mogelijke reiswegen en alle mogelijk bediende haltes.

Makkelijk gezegd: ga je met de data een echte applicatie als een
routeplanner maken, dan wordt he pas een "probleem", al is het toch
niet meer dan op de juiste uren van de dag te linken naar de juiste
relaties die de stukjes van de buslijn vormen.

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-11 Thread Ivo De Broeck
Je opmerking over verkorte ritten lijkt mij belangrijk. Dit hangt volledig
samen met de uurtabellen. Zo maakt "De Lijn" telkens het onderscheid tussen
weekdagen, zaterdagen en zondagen voor de "normale" lijnen. Bij schoolbussen
en andere speciale lijnen, kan het nog iets ingewikkelder.
Het lijkt mij zinvol om de wiki grondig (en duidelijk) om te vormen.

Op 10 oktober 2010 21:10 schreef Jo  het volgende:

> Ivo, ik zou op de wikipagina beschrijven dat er een heen- en een terugroute
> gemapt wordt. Dat is de enige wijze waar een routeplanner iets aan heeft.
> Als mensen het dan toch met 1 route/buslijn blijven mappen, dan betekent dat
> weer werk voor iemand die wel weet waar hij mee bezig is, om ze te
> ontdubbelen. De reden waarom 'k De Lijn had aangeschreven, was eigenlijk
> voornamelijk omdat 'k hun datamodel had willen zien. Ik vermoed namelijk dat
> we er zelfs met 2 relaties/lijn niet gaan komen. Wat met verkorte ritten?
> Wat met ritten die soms een andere route volgen, afh. vd dag van de week. Ik
> denk bijv. aan lijn 630. Die het industrieterrein niet bedient tijdens het
> weekeinde en die dan een stukje expressweg volgt. Of dat voor die lijn
> belang heeft, is natuurlijk de vraag. Als je de 'schedule' erbij neemt, is
> het wel duidelijk welke haltes wel of niet bediend worden. Maar dat is nu
> net het stukje dat we niet kwijt kunnen in de OSM-database.
>
> Het experiment met de child relations zou 'k maar niet vermelden, de kans
> dat dat bruikbaar is voor een routeplanner, is klein. Het zou een
> aanzienlijke tijdsbesparing kunnen betekenen, omdat het redundante
> informatie minimaliseert, maar het maakt het ook complexer. De pluging in
> JOSM kan er alleszins niet mee overweg.
>
> Ben, moeten we stemmen over 1 of 2 relaties/busroute? Of kunnen we ervan
> uitgaan dat iedereen inziet dat dat de correcte manier van werken is? Wie
> dat niet ziet, zou Oxomoa er 's op moeten nalezen. Die mensen hebben daar
> hard over nagedacht voordat ze dat document maakten.
>
> Jo
>
>
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-10 Thread Jo
Ivo, ik zou op de wikipagina beschrijven dat er een heen- en een terugroute
gemapt wordt. Dat is de enige wijze waar een routeplanner iets aan heeft.
Als mensen het dan toch met 1 route/buslijn blijven mappen, dan betekent dat
weer werk voor iemand die wel weet waar hij mee bezig is, om ze te
ontdubbelen. De reden waarom 'k De Lijn had aangeschreven, was eigenlijk
voornamelijk omdat 'k hun datamodel had willen zien. Ik vermoed namelijk dat
we er zelfs met 2 relaties/lijn niet gaan komen. Wat met verkorte ritten?
Wat met ritten die soms een andere route volgen, afh. vd dag van de week. Ik
denk bijv. aan lijn 630. Die het industrieterrein niet bedient tijdens het
weekeinde en die dan een stukje expressweg volgt. Of dat voor die lijn
belang heeft, is natuurlijk de vraag. Als je de 'schedule' erbij neemt, is
het wel duidelijk welke haltes wel of niet bediend worden. Maar dat is nu
net het stukje dat we niet kwijt kunnen in de OSM-database.

Het experiment met de child relations zou 'k maar niet vermelden, de kans
dat dat bruikbaar is voor een routeplanner, is klein. Het zou een
aanzienlijke tijdsbesparing kunnen betekenen, omdat het redundante
informatie minimaliseert, maar het maakt het ook complexer. De pluging in
JOSM kan er alleszins niet mee overweg.

Ben, moeten we stemmen over 1 of 2 relaties/busroute? Of kunnen we ervan
uitgaan dat iedereen inziet dat dat de correcte manier van werken is? Wie
dat niet ziet, zou Oxomoa er 's op moeten nalezen. Die mensen hebben daar
hard over nagedacht voordat ze dat document maakten.

Jo


Op 10 oktober 2010 18:25 schreef Ivo De Broeck  het
volgende:

> Ben,
>
> OK welke procedure? opmerkingen op de overlegpagina? discussie op talk-be?
> stemming?
>
> Het eerste probleem is dat van 1 of 2 relaties. Hoe wordt die knoop
> doorgehakt?? Mensen waren ervoor, ik begreep dat jij daar niet echt
> voorstander van was. Hoe moet het nu verder?? Ik had op 15/9 zes (tamelijk
> ingewikkelde) complete routes gemaakt, die  naar mijn gevoel een perfect
> resultaat gaven.
>
> Hoe wordt bepaald dat we nu met 1 of 2 relaties werken?
>
> Ivo
>
> Op 10 oktober 2010 12:34 schreef Ben Laenen  het
> volgende:
>
> Ivo De Broeck wrote:
>> > Ben,
>> >
>> > ref=8 zal denk ik meer dan 50 keer voorkomen. In Antwerpen, Mechelen,
>> > Turnhout enz
>>
>> En dan? Daar is toch geen probleem mee? In Antwerpen ga ik niet per
>> ongeluk de
>> bus 8 die in Leuven rondrijdt nemen hoor :-)
>>
>> In de data van de lijn staat ook enkel het nummer onder
>> route_public_identifier. Het verschil wordt dan wel gemaakt door (naast de
>> route_identifier) de route_description (wat we tot nu steeds in name=*
>> hebben
>> gezet)
>>
>> > Wat De Lijn betreft, zij werken wel degelijk met "trips" en niet met
>> > gesloten routes.
>>
>> Zag ik ook al, maar had nog niet onderzocht hoe ver zo'n trip dan juist is
>> (i.e. terminus tot terminus, een volledige ronde, of tussen kleinere
>> knooppunten waardoor terminus tot terminus verschillende trips omvat)
>>
>> Willen we structuur van data van De Lijn overnemen lijkt het alsof we een
>> tram- of buslijn een parentrelatie moeten geven met de gegevens als
>> lijnnummer, route_description. En dan voor elke trip met de
>> route_identifier
>> van de buslijn een childrelatie waar dan de stops in zitten.
>>
>> Alleen, hoe gaan we dat allemaal compatibel krijgen met de bestaande
>> renderers
>> als öpnv-karte?
>>
>> > Discussie op mailinglist, akkoord zodra we er in slagen een volledig
>> > uitgewerkt voorstel te formuleren na heel wat studie en probeersels (jo
>> > experimenteert oa met child-relaties en bus-stations). Het lijkt mij nu
>> > belangrijk dat we ervaring opdoen en uw inbreng wordt zeker op prijs
>> > gesteld. Het heeft imho weinig zin een welles-nietes discussie nu op de
>> > mailinglist te plaatsen.
>>
>> Wel, dit is een moeilijk probleem en hoe meer er kunnen meedenken hoe
>> beter.
>> Communityles nummer 1: wil je dat je oplossing aanvaard wordt door de
>> community, dan moet je die laten mee discussiëren. Zoniet dan wordt het
>> juist
>> een welles-nietesdiscussie. Hoe denk je dat al het gedoe over ODbL is
>> ontstaan?
>>
>> > Ik stel voor ons nog een maand de tijd te laten en daarna gooien we het
>> op
>> > de mailinglist en stemmen we over een definitieve conventie. Lijkt je
>> dat
>> > een goede werkwijze?
>>
>> Nee dus
>>
>> Ben
>>
>
>
>
> --
> Ivo De Broeck
> Valleilaan 13
> 3360  Korbeek-lo
> Tel (0)16 43 84 93
> Gsm +32 486 17 61 13
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-09 Thread Ben Laenen
Jo wrote:
> De bussen in Leuven die met moderne displays rijden, beginnen allemaal een
> kleur op de achtergrond te krijgen. Eerst waren het enkel de bussen die de
> luchthaven bedienden, maar nu zie 'k die kleuren ook al op de andere
> lijnen. Het zou natuurlijk mooi zijn als het met die kleur gerenderd werd.
> Op openbusmap.org zijn alle bussen echter rood (en die kaart loopt fameus
> achter op de feiten).

De Lijn is ook bezig (op gezapig tempo weliswaar) om de bushaltes te voorzien 
van nieuwe halteborden waar de kleur van de buslijn gebruikt wordt, zoals 
http://www.uitweg.be/uitweg67/beelden/uitweg67_bushalte_signalisatie.jpg

Verder is de kleur sowieso al te zien op de tijdstabellen die aan elke halte 
hangen, en op de netkaarten.

Ben

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


Re: [OSM-talk-be] busroutes

2010-10-09 Thread Jo
De bussen in Leuven die met moderne displays rijden, beginnen allemaal een
kleur op de achtergrond te krijgen. Eerst waren het enkel de bussen die de
luchthaven bedienden, maar nu zie 'k die kleuren ook al op de andere lijnen.
Het zou natuurlijk mooi zijn als het met die kleur gerenderd werd. Op
openbusmap.org zijn alle bussen echter rood (en die kaart loopt fameus
achter op de feiten).

Jo

Op 9 oktober 2010 16:57 schreef Ivo De Broeck  het
volgende:

> Ben,
>
> 1) Tja zwart en wit zijn natuurlijk ook kleuren, misschien de tekstkleur
> als optioneel aangeven
> 2) nat_ref lijkt mij wel nuttig nat_ref zou bv DL LEUVEN stadsbus 8 (of
> zoiets kunnen zijn) de operator en UNIEKE aanduiding van de buslijn
> 3) ref waarom alleen een nummer? 8 lijkt mijn geen goede referte voor de
> stadsbus nr 8 in xx aantal steden, ik beschouw ref als wat op de bus staat
> dus
> ref = 8 Bierbeek - De Borre (via Bremt) en die uniek is. Is natuurlijk
> alleen zinvol wanneer we aparte relaties gebruiken van A naar B en van B
> naar A
>
> Ivo
>
> Op 9 oktober 2010 15:16 schreef Ben Laenen  het
> volgende:
>
> Ben Laenen wrote:
>> > Ivo De Broeck wrote:
>> > > * color is in colour gewijzigd
>> >
>> > nog een kleine opmerking wat betreft text_colour: 99.9% van alle lijnen
>> in
>> > Vlaanderen heeft geen aparte tekstkleur, dus dat moet je er misschien
>> > bijzetten op de wiki. De enige uitzonderingen die ik ken zijn tramlijnen
>> 11
>> > (rood op wit) en 15 (groen op wit) in Antwerpen. Voor de rest kan je
>> > natuurlijk wit of zwart als tekstkleur ingeven zoals het op de bus
>> > verschijnt, maar als je het dan weer op papier bekijkt kan het al
>> > omgekeerd zijn.
>> >
>> > Wat is trouwens de nat_ref in de tabel? Ken je één lijn waar dat nodig
>> is?
>>
>> Oeps, te snel weg. Wou ook nog dit zeggen:
>>
>> In de ref=* mag enkel het lijnnummer. Geen bestemmingen of wat dan ook.
>> Daar
>> kan je andere tags voor vinden (en totnutoe was dat meestal name=*).
>>
>> Ben
>>
>
>
>
> --
> Ivo De Broeck
> Valleilaan 13
> 3360  Korbeek-lo
> Tel (0)16 43 84 93
> Gsm +32 486 17 61 13
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-10-09 Thread Jo
Toen ik 2-3 jaar geleden een paar busroutes heb ingegeven, heb ' k dat met 1
relatie gedaan voor beide richtingen. Dat is OK, als je enkel interesse hebt
in een rendering op de kaart. Sinds 'k Oxomoa gelezen heb, is het me echter
duidelijk dat een relatie per richting de enig correcte manier is, als je
wil dat het bruikbaar is voor automatische planners. Het is de enige manier
waarop op niet-mis-te-verstane wijze duidelijk wordt hoe zo'n bus rijdt. In
sommige gevallen komt een 'way' ook meermaals voor in dezelfde uitgesplitste
route.

Wat wel nog een probleem is, is het volgende: beperkte ritten. Lijn 8 gaat
in principe tot Bierbeek De Borre. Maar sommige ritten gaan maar tot
Bierbeek Bremt. Is dat een compleet andere relatie (x2)? Of kunnen we dat op
de een of andere wijze toch oplossen met 1 relatie. Ik weet ook niet of we
in Belgie busroutes hebben die de ene keer 1 tak volgen en de andere keer
een andere tak (Y).

Ik ben ook wat aan het experimenteren geweest met child relations, omdat
veel van die buskilometer over dezelfde stukken asfalt gaan. Het wordt
correct gerenderd. Het wordt wat complexer, maar wel iets vlotter om
achteraf een wijziging 1x te doen, i.p.v. 20x (wegomlegging omwille van
Fochplein, bv). Het is waarschijnlijk een nachtmerrie voor
routerapplicaties... Geen idee eigenlijk. Op dit moment heb ' k die child
relations nog niet in 2 richtingen gedaan, omdat het wschl een dood spoor
is.

Groeten,

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


Re: [OSM-talk-be] busroutes

2010-08-18 Thread Ben Laenen
Ivo De Broeck wrote:
> Its not forbidden to put a link to another website.

It is forbidden to make this data available online, like Marc did.

And it's careless to link to this data on places like this mailing list: if we 
ever go out to hunt for available data that we can import in OSM, and they see 
that data like this was just made available without permission, now that 
doesn't give a very good impression, does it?

And really, I don't care if Marc throws data like this online without 
permission. As long as he does it without any reference to the OSM project.

Greetings
Ben


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


Re: [OSM-talk-be] busroutes

2010-08-18 Thread Ivo De Broeck
2010/8/17 Ben Laenen 

> Ivo De Broeck wrote:
>


> > I suppose some data can be used in OSM. So it must be possible to load
> all
> > bus_stops from "vvm_stop" in batch in OSM?
>
>
> Only put in OSM what we're allowed to put in. Marc got this data for
> research
> purposes, he never got permission to put it in OSM. He doesn't care about
> that, but the rest of us do. There are a lot of things that can be said
> about
> whether the data should be free to use (or maybe is with the law about
> database rights), but I'd like to see it more thoroughly investigated
> before
> any of this data gets in OSM than someone saying "I think it's fine". And
> in
> fact I hate that this database was made available to download without
> permission with a link on our mailing list given that OSM is so careful
> about
> license issues.
>
> Greetings
> Ben
>

Its not forbidden to put a link to another website.

It was very interesting to analyze the database of De Lijn. It convinced me
that there is no relation such as "stadsbus 8" but "trips" like "from A to B
via C".
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Ben Laenen
Ivo De Broeck wrote:
> 2010/8/10 Marc Coevoet 
> 
> I have all the data from delijn.be .
> 
> > Somebody can always come and discuss ;-)
> > 
> > I was stupid , did not look to those files. Now i see "De Lijn" works
> > with "vvm_trips" between "vvm_places".
> 
> I suppose some data can be used in OSM. So it must be possible to load all
> bus_stops from "vvm_stop" in batch in OSM?


Only put in OSM what we're allowed to put in. Marc got this data for research 
purposes, he never got permission to put it in OSM. He doesn't care about 
that, but the rest of us do. There are a lot of things that can be said about 
whether the data should be free to use (or maybe is with the law about 
database rights), but I'd like to see it more thoroughly investigated before 
any of this data gets in OSM than someone saying "I think it's fine". And in 
fact I hate that this database was made available to download without 
permission with a link on our mailing list given that OSM is so careful about 
license issues.

Greetings
Ben

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


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Ivo De Broeck
2010/8/10 Marc Coevoet 

I have all the data from delijn.be .
>
> Somebody can always come and discuss ;-)
>
>
>
>
> http://www.mediafire.com/file/nnjuimwwmm2/generalexport_2010-02-18.zip
>
> description:
> http://www.mediafire.com/file/myvn5f4iqtu/interface%20delijndata_v1_03.pdf
>
> I was stupid , did not look to those files. Now i see "De Lijn" works with
"vvm_trips" between "vvm_places".

I suppose some data can be used in OSM. So it must be possible to load all
bus_stops from "vvm_stop" in batch in OSM?

I think i could end the discussion about the two relations (one backward,
one forward). The only good thing of my experiment is that i have fixed some
broken connections between some ways in OSM to have a one piece relation.
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Denis Jacquerye
On Tue, Aug 17, 2010 at 3:52 PM, Ivo De Broeck  wrote:
> 2010/8/17 Ben Laenen 
>
>>
>> On a side note: please don't give bus line refs an extra asterisk to make
>> the
>> distinction between the two relations.
>>
> ?
> Would 8 b better then 8 * and why?

No, the reference is still 8.

Cheers,
Denis Moyogo Jacquerye

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


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Ivo De Broeck
2010/8/17 Ben Laenen 


> On a side note: please don't give bus line refs an extra asterisk to make
> the
> distinction between the two relations.
>
> ?

Would 8 b better then 8 * and why?
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Ben Laenen
Ivo De Broeck wrote:
> 2010/8/17 Ben Laenen 
> > What problems of a terminus? Terminus halts just get a "terminus" role in
> > the
> > relation. And if one end of the line isn't a terminus stop, but a normal
> > halt
> > where it just turns back without waiting it doesn't get a terminus role
> > but it's tagged as any other bus stop.
> 
> The bus 9 from Bertem arrives at xx:34 at Pimberg. After 14 minutes (at
> xx:48) it follows the route back to Bertem. Is Pimberg a normal bus_stop or
> a terminus?

It's a waiting point (where the driver can rest for a little while), so it's a 
terminus. Sometimes (usually in cities where there's not much place to stop) 
you have buses that don't stop like that at the end of the line: like any 
other stop they just leave immediately after they've arrived and everyone got 
on and off the bus. Sure, it's not really common, but we have to keep it in 
mind. In Antwerp we have tram lines (which we really want to be tagged like 
bus lines) 10 and 11 for example.


Also, we do have another problem with the one relation for each direction 
thing. There's the bus lines 30 and 34 in Antwerp. These two lines are 
basically oneway loops around the city center (and bus 34 goes the other way 
than bus 30). There's a terminus along the way, but you can't define that 
being at the start or end of the relation. How's that going to work without 
relation roles?


On a side note: please don't give bus line refs an extra asterisk to make the 
distinction between the two relations.


Ben

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


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Ivo De Broeck
2010/8/17 Ben Laenen 

> Ivo De Broeck wrote:
> > Using 2 different relations solve also the problem of a terminus. See
> > http://www.openstreetmap.org/edit?lat=50.85077&lon=4.75625&zoom=17 for
> the
> > example 'Pimberg" (end of line 9 Bertem-Leuven-Pimberg). The 9* is the
> > route backward (Pimberg - Leuven - Bertem).
>
> What problems of a terminus? Terminus halts just get a "terminus" role in
> the
> relation. And if one end of the line isn't a terminus stop, but a normal
> halt
> where it just turns back without waiting it doesn't get a terminus role but
> it's tagged as any other bus stop.
>

The bus 9 from Bertem arrives at xx:34 at Pimberg. After 14 minutes (at
xx:48) it follows the route back to Bertem. Is Pimberg a normal bus_stop or
a terminus?

>
> With two relations but without roles you lose that information whether it's
> a
> terminus or just a halt where it turns back.
>

I thought a terminus is the start (or/and end) of the relation. If the
terminal is defined as the place where the busses sleeps at night (and where
you can only get the bus once or twice a day) i think its useless to take
that information on OSM.

It looks me more important to have the information of the bus_stops on OSM.
That includes the position, the name, the ref (from de Lijn) the zone and
all possible routes  (included with their direction). See
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines#Bus_stops_De_Lijn

Can I remove Todo on
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines#TODO?

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



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Ben Laenen
Ivo De Broeck wrote:
> Using 2 different relations solve also the problem of a terminus. See
> http://www.openstreetmap.org/edit?lat=50.85077&lon=4.75625&zoom=17 for the
> example 'Pimberg" (end of line 9 Bertem-Leuven-Pimberg). The 9* is the
> route backward (Pimberg - Leuven - Bertem).

What problems of a terminus? Terminus halts just get a "terminus" role in the 
relation. And if one end of the line isn't a terminus stop, but a normal halt 
where it just turns back without waiting it doesn't get a terminus role but 
it's tagged as any other bus stop.

With two relations but without roles you lose that information whether it's a 
terminus or just a halt where it turns back.

Ben

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


Re: [OSM-talk-be] busroutes

2010-08-17 Thread Ivo De Broeck
Using 2 different relations solve also the problem of a terminus. See
http://www.openstreetmap.org/edit?lat=50.85077&lon=4.75625&zoom=17 for the
example 'Pimberg" (end of line 9 Bertem-Leuven-Pimberg). The 9* is the route
backward (Pimberg - Leuven - Bertem).

See also
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines#Bus_stops_De_Lijnabout
bus_stops.
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-12 Thread Ben Laenen
On Thu, Aug 12, 2010 at 10:48 AM, Ivo De Broeck  wrote:
> I do not understand this. I have used Potlatch and have put in disorder all
> members of the relation. Then i have used the relationchecker and all
> members came in the right way. This was for a oneway buss-route.

The relation analyzer will reorder them on the page, but they are not
in order in the database. There's btw an equally great chance that the
analyzer will return them in opposite order from end to start (it
depends on which way it chooses first and which it selects after that,
without changing the relation the analyzer will always give the same
order normally). The order you get on that page is not how they're in
the database. You can check the real order with JOSM or just in the
browse pages of the API.

> When i
> tried to put the backward route, all members were in disorder.
> This is a normal buss-route: (F=forward / B=backward)
>                       B
> begin --F/B-<>--F/Bend
>                       F

You have to know what the analyzer does and doesn't do. So in short:
it groups the members with the same role (so, all "backward" will be
grouped separately from all members with an empty role, etc), and then
it reorders the ways so each group gets as large routes as possible
(not exactly like that, but it'll do as explanation).

So since we have forward/backward/empty roles, it will automatically
not give good results. You'd have the same problem if you'd add only
one direction of the route and added backward/forward roles (try the
analyzer on some local walking routes around Antwerp for example).

Basically, the analyzer isn't really good for two-directional routes.

> Can we discuss further
> at http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Belgium/Conventions/Bus_and_tram_lines
> ??

I don't see a reason why we'd move discussion over there? It's more
visible over here and more people are likely to participate in the
discussion here.

Greetings
Ben

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


Re: [OSM-talk-be] busroutes

2010-08-12 Thread Ivo De Broeck
2010/8/11 Ben Laenen 

> Renaud MICHEL wrote:
> > Le mercredi 11 août 2010 à 13:26, Ben Laenen a écrit :
> > > You could fill in the roles of those nodes in the relation of course.
> > > I've  even seen the bus stop nodes being numbered, so you'd get
> > > something like "stop_15" as a role.
> >
> > The number was used before API0.6, when relations didn't preserve
> ordering,
> > see
> > http://wiki.openstreetmap.org/wiki/Tag:type=route#Members
>
> As said before, at least one of the main editors (Potlatch) will destroy
> order
> and any duplicate members in the relation if you edit it (by e.g. splitting
> a
> way which is a member of that relation), and therefore we still can't rely
> on
> it. If we could, there wouldn't be a problem and we could just use one
> relation and just add all ways in order.
>
> I do not understand this. I have used Potlatch and have put *in disorder*all 
> members of the relation. Then i have used the relationchecker and all
members came in the right way. This was for a oneway buss-route. When i
tried to put the backward route, all members were in disorder.

This is a normal buss-route: (F=forward / B=backward)
  B
begin --F/B-<>--F/Bend
  F

Can we discuss further at
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Belgium/Conventions/Bus_and_tram_lines??

Greetings
> Ben
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-11 Thread Ben Laenen
Renaud MICHEL wrote:
> Le mercredi 11 août 2010 à 13:26, Ben Laenen a écrit :
> > You could fill in the roles of those nodes in the relation of course.
> > I've  even seen the bus stop nodes being numbered, so you'd get
> > something like "stop_15" as a role.
> 
> The number was used before API0.6, when relations didn't preserve ordering,
> see
> http://wiki.openstreetmap.org/wiki/Tag:type=route#Members

As said before, at least one of the main editors (Potlatch) will destroy order 
and any duplicate members in the relation if you edit it (by e.g. splitting a 
way which is a member of that relation), and therefore we still can't rely on 
it. If we could, there wouldn't be a problem and we could just use one 
relation and just add all ways in order.

Greetings
Ben

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


Re: [OSM-talk-be] busroutes

2010-08-11 Thread Renaud MICHEL
Le mercredi 11 août 2010 à 13:26, Ben Laenen a écrit :
> You could fill in the roles of those nodes in the relation of course.
> I've  even seen the bus stop nodes being numbered, so you'd get
> something like "stop_15" as a role.

The number was used before API0.6, when relations didn't preserve ordering, 
see
http://wiki.openstreetmap.org/wiki/Tag:type=route#Members

-- 
Renaud Michel

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


Re: [OSM-talk-be] busroutes

2010-08-11 Thread Ben Laenen
Ivo De Broeck wrote:
> With 2 relations you can put the stops at the right relation. If you work
> with one relation you have a way in both directions, a stop 'forward' and a
> stop 'backward' .

You could fill in the roles of those nodes in the relation of course. I've 
even seen the bus stop nodes being numbered, so you'd get something like 
"stop_15" as a role. But that's hard to maintain (think about adding an extra 
bus stop between stop 1 and 2, then you can renumber them all). Other option 
is to have roles saying something like "to_terminus_2".

But if you assume that bus stop nodes are always at the right side of the 
road, that's more than enough information to know in which direction the bus 
has to go to stop there.

Greetings
Ben

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


Re: [OSM-talk-be] busroutes

2010-08-11 Thread Ivo De Broeck
2010/8/10 Ben Laenen 

> Maarten Deen wrote:
> > Have a look at http://wiki.openstreetmap.org/wiki/VRS , for a lot of
> > relations, there are two routes. Often also tagged with a from and to in
> > the relation, although I don't know if that really helps in a program.
>
> "a lot of relations": I count 12 on that page with two relations, given the
> number of routes on it I wouldn't really call that "a lot" :-)
>
>
> Anyway, I personally don't see why splitting the relation in two would be
> so
> much better. Basically the only reason why you'd do it because it tags a
> little bit easier since you don't have to add 'forward' and 'backward'
> roles.
> It doesn't solve anything else: the ambiguous possibilities to follow a
> route
> when a bus makes loops are all still there for example.
>

With 2 relations you can put the stops at the right relation. If you work
with one relation you have a way in both directions, a stop 'forward' and a
stop 'backward' .

>
> IMHO, the best option would be to stick with just one relation, but map it
> differently: take a starting point on the bus route and then just add the
> ways
> in the order the bus follows them to get to the other end, and then add the
> ways in order as the bus goes back to the start point (so usually adding
> the
> same ways to this relation again). In principle, you don't need
> forward/backward tags with that either.
>
> Alas, we have problems with this since one of the main editors can't handle
> ways that belong multiple times to the same (so if someone else e.g. splits
> up
> a way in that editor the relation is broken), and it doesn't keep the order
> of
> the members in the relation.
>
>
> I have the impression that making two relations of them is trying to patch
> this: avoid ways that belong multiple times to the same relation by putting
> them in two different ones. This doesn't work properly btw, since I know
> bus
> routes that go up and down the same road in both directions between the
> termini. One could suggest the topology of the ways belonging the unordered
> relation would always make it possible to get the exact way order the bus
> follows, but I'm not really convinced of that yet. Certainly if you drop
> the
> forward/backward roles: then you really cannot know anymore in which
> direction
> the bus rides a loop in its route. And for now I can see only one thing two
> relations without forward/backward can represent more that one with
> forward/backward: if the bus follows a loop in one direction, but doesn't
> follow it in the other. But if that's worth it to start tagging something
> differently? Better to wait for when Potlatch can finally handle relations
> nicely and map the bus routes properly instead of going to this
> intermediate
> method that doesn't bring much advantages and brings its own problems.


I agree. That s why intermediate it seems a good idea to work with 2
relations. It will be easy to merge (if necessary) the two relations.

>


> Greetings
> Ben
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ben Laenen
Maarten Deen wrote:
> Have a look at http://wiki.openstreetmap.org/wiki/VRS , for a lot of
> relations, there are two routes. Often also tagged with a from and to in
> the relation, although I don't know if that really helps in a program.

"a lot of relations": I count 12 on that page with two relations, given the 
number of routes on it I wouldn't really call that "a lot" :-)


Anyway, I personally don't see why splitting the relation in two would be so 
much better. Basically the only reason why you'd do it because it tags a 
little bit easier since you don't have to add 'forward' and 'backward' roles. 
It doesn't solve anything else: the ambiguous possibilities to follow a route 
when a bus makes loops are all still there for example.

IMHO, the best option would be to stick with just one relation, but map it 
differently: take a starting point on the bus route and then just add the ways 
in the order the bus follows them to get to the other end, and then add the 
ways in order as the bus goes back to the start point (so usually adding the 
same ways to this relation again). In principle, you don't need 
forward/backward tags with that either.

Alas, we have problems with this since one of the main editors can't handle 
ways that belong multiple times to the same (so if someone else e.g. splits up 
a way in that editor the relation is broken), and it doesn't keep the order of 
the members in the relation.


I have the impression that making two relations of them is trying to patch 
this: avoid ways that belong multiple times to the same relation by putting 
them in two different ones. This doesn't work properly btw, since I know bus 
routes that go up and down the same road in both directions between the 
termini. One could suggest the topology of the ways belonging the unordered 
relation would always make it possible to get the exact way order the bus 
follows, but I'm not really convinced of that yet. Certainly if you drop the 
forward/backward roles: then you really cannot know anymore in which direction 
the bus rides a loop in its route. And for now I can see only one thing two 
relations without forward/backward can represent more that one with 
forward/backward: if the bus follows a loop in one direction, but doesn't 
follow it in the other. But if that's worth it to start tagging something 
differently? Better to wait for when Potlatch can finally handle relations 
nicely and map the bus routes properly instead of going to this intermediate 
method that doesn't bring much advantages and brings its own problems.

Greetings
Ben


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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ben Laenen
Ivo De Broeck wrote:
> see
> http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_
> tram_lines#Tagging(to discuss)

Watch out when editing the wiki: you've replaced the paragraph about tagging 
"belbussen". Furthermore, when starting a discussion on the wiki, this should 
go on the talk page before putting it on the conventions page itself when a 
consensus is reached.

Greetings
Ben


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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ivo De Broeck
2010/8/10 Renaud MICHEL 
>

> Le mardi 10 août 2010 à 10:22, Tim Francois a écrit :
> > +1. Yup, this is what is currently happening in most of the UK - a
> > separate relation for the 'up' and 'down' bus routes, so that
> > forwards/backwards (which is kinda broken as a concept in this case)
> > is not required!
>
> I'm interested, for now I have created single relation for a bus route in
> Liège.
> How should I tag the two separate relations?
>
> The page
> http://wiki.openstreetmap.org/wiki/Buses
> doesn't talk about double relation, but suggests that bus_stop should be
> put
> on the way, but the bus stops are not on the road but along it.
>

see
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines#Tagging(to
discuss)

>
> --
> Renaud Michel
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ivo De Broeck
2010/8/10 Renaud MICHEL 
>

> Le mardi 10 août 2010 à 10:22, Tim Francois a écrit :
> > +1. Yup, this is what is currently happening in most of the UK - a
> > separate relation for the 'up' and 'down' bus routes, so that
> > forwards/backwards (which is kinda broken as a concept in this case)
> > is not required!
>
> I'm interested, for now I have created single relation for a bus route in
> Liège.
> How should I tag the two separate relations?
>
> see the example on
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Public_Transport#Stad_Leuven(bus
8)


> The page
> http://wiki.openstreetmap.org/wiki/Buses
> doesn't talk about double relation, but suggests that bus_stop should be
> put
> on the way, but the bus stops are not on the road but along it.
>
> --
> Renaud Michel
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ivo De Broeck
Op 10 augustus 2010 12:35 schreef Ben Laenen  het
volgende:

> Maarten Deen wrote:
> > > Een oplossing zou natuurlijk kunnen bestaan uit het maken van 2
> > > relaties :
> > > relatie x 8 Bertem -> Bierbeek
> > > relatie y 8 Bierbeek -> Bertem
> >
> > Dat is wat op veel plaatsen toch al gedaan wordt. En dan geen forward
> > of backward er in. Ik zou zeggen: de eerste node/way in de relatie geeft
> > aan waar gestart wordt.
>
> Alleen spijtig dat sommige editors de volgorde van relatiemembers graag
> door
> elkaar schudden, dat "de eerste node/way in de relatie" kan veranderen
> zonder
> dat je het doorhebt.
>
> Daarnaast, stel dat in plaats van een terminus op het einde van een
> busroute,
> de bus een lus maakt vooraleer in de tegengestelde richting te komen zonder
> ergens terminusgewijs wat langer halt te houden. Waar begint en eindigt dan
> de
> heen- en terugrelatie?
>

Lijkt mij geen probleem. Die lus steekt je gewoon bij het einde van de
terugweg of bij het begin van de "forward-route"

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



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Renaud MICHEL
Le mardi 10 août 2010 à 12:41, Ben Laenen a écrit :
> Yes, please put the bus stop nodes next to the way, not on the way.

OK, that seems more logical anyway.

> btw, the page talks about an *extra* node on the way, used together with
> the bus stop node next to the way.

Is it useful?
If I split the route in two relations, forward and backward, most bus stops 
will only be part of one relation or the other.

-- 
Renaud Michel

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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ben Laenen
Renaud MICHEL wrote:
> The page
> http://wiki.openstreetmap.org/wiki/Buses
> doesn't talk about double relation, but suggests that bus_stop should be
> put on the way, but the bus stops are not on the road but along it.

Yes, please put the bus stop nodes next to the way, not on the way.

btw, the page talks about an *extra* node on the way, used together with the 
bus stop node next to the way.

Ben

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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ben Laenen
Maarten Deen wrote:
> > Een oplossing zou natuurlijk kunnen bestaan uit het maken van 2
> > relaties : 
> > relatie x 8 Bertem -> Bierbeek 
> > relatie y 8 Bierbeek -> Bertem
> 
> Dat is wat op veel plaatsen toch al gedaan wordt. En dan geen forward
> of backward er in. Ik zou zeggen: de eerste node/way in de relatie geeft
> aan waar gestart wordt.

Alleen spijtig dat sommige editors de volgorde van relatiemembers graag door 
elkaar schudden, dat "de eerste node/way in de relatie" kan veranderen zonder 
dat je het doorhebt.

Daarnaast, stel dat in plaats van een terminus op het einde van een busroute, 
de bus een lus maakt vooraleer in de tegengestelde richting te komen zonder 
ergens terminusgewijs wat langer halt te houden. Waar begint en eindigt dan de 
heen- en terugrelatie?

Ben

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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ivo De Broeck
2010/8/10 Maarten Deen 

> On Tue, 10 Aug 2010 10:56:28 +0200, Ivo De Broeck
>  wrote:
> > What i propose is keeping the existing relation for the "normal"
> > direction.
>
> There is no "normal" direction with buses.
>

Yes the "normal" name for the route is "8 Bertem- Leuven - Bierbeek"
On relation one are busses with : 8 BIERBEEK
On relation two are busses with : 8 BERTEM

>
> > Example stadsbus nr 8 go from Bertem - Leuven - Bierbeek (check the
> > relation with the relation checker). Give the same relationnumber to
> > all bus-stops for that direction.
>
> You mean: add the stops to the relation.
>
> >  If you are in Leuven you can choose the bus 8 to Bierbeek (relation
> > one) OR bus 8 to Bertem (relation 2).
>
> And there comes the part for the "from" and "to" tags in the relation
> which I thought had no use. You always "take line X towards Y". And
> having the from and to in the relation will specify Y.
>

Right, there are no tags forward or backward.

>
> Oh, and
> 
> has a more elaborate tagging scheme.
>

We need now, a working convention for busses.

>
> Regards,
> Maarten
>
> > 2010/8/10 Renaud MICHEL
> >  Le mardi 10 août 2010 à 10:22, Tim Francois a écrit :
> >
> >> +1. Yup, this is what is currently happening in most of the UK - a
> >  > separate relation for the 'up' and 'down' bus routes, so that
> >  > forwards/backwards (which is kinda broken as a concept in this
> > case)
> >  > is not required!
> >
> >  I'm interested, for now I have created single relation for a bus
> > route in
> >  Liège.
> >  How should I tag the two separate relations?
> >
> >  The page
> >  http://wiki.openstreetmap.org/wiki/Buses [2]
> >  doesn't talk about double relation, but suggests that bus_stop
> > should be put
> >  on the way, but the bus stops are not on the road but along it.
> >
> >  --
> >  Renaud Michel
> >
> >  ___
> >  Talk-be mailing list
> >  Talk-be@openstreetmap.org [3]
> >  http://lists.openstreetmap.org/listinfo/talk-be [4]
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Maarten Deen
On Tue, 10 Aug 2010 11:21:17 +0200, Maarten Deen 
wrote:

> 
> has a more elaborate tagging scheme.

I see Oxomoa flags this page as out of dat himself, but IMHO the
 page is not very
elaborate.
That needs more discussion on the talk page I think.

Regards,
Maarten


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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Maarten Deen
On Tue, 10 Aug 2010 10:56:28 +0200, Ivo De Broeck
 wrote:
> What i propose is keeping the existing relation for the "normal"
> direction.

There is no "normal" direction with buses.

> Example stadsbus nr 8 go from Bertem - Leuven - Bierbeek (check the
> relation with the relation checker). Give the same relationnumber to
> all bus-stops for that direction. 

You mean: add the stops to the relation.

>  If you are in Leuven you can choose the bus 8 to Bierbeek (relation
> one) OR bus 8 to Bertem (relation 2).

And there comes the part for the "from" and "to" tags in the relation
which I thought had no use. You always "take line X towards Y". And
having the from and to in the relation will specify Y.

Oh, and

has a more elaborate tagging scheme.

Regards,
Maarten

> 2010/8/10 Renaud MICHEL 
>  Le mardi 10 août 2010 à 10:22, Tim Francois a écrit :
> 
>> +1. Yup, this is what is currently happening in most of the UK - a
>  > separate relation for the 'up' and 'down' bus routes, so that
>  > forwards/backwards (which is kinda broken as a concept in this
> case)
>  > is not required!
> 
>  I'm interested, for now I have created single relation for a bus
> route in
>  Liège.
>  How should I tag the two separate relations?
> 
>  The page
>  http://wiki.openstreetmap.org/wiki/Buses [2]
>  doesn't talk about double relation, but suggests that bus_stop
> should be put
>  on the way, but the bus stops are not on the road but along it.
> 
>  --
>  Renaud Michel
> 
>  ___
>  Talk-be mailing list
>  Talk-be@openstreetmap.org [3]
>  http://lists.openstreetmap.org/listinfo/talk-be [4]


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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ivo De Broeck
What i propose is keeping the existing relation for the "normal" direction.
Example stadsbus nr 8 go from Bertem - Leuven - Bierbeek (check the relation
with the relation checker). Give the same relationnumber to all bus-stops
for that direction.

Make a complete new relation for the backward direction. Check the route,
Give the bus-stops that new relation number.
Example stadsbus nr 8 Bierbeek - Leuven - Bertem

If you are in Leuven you can choose the bus 8 to Bierbeek (relation one) OR
bus 8 to Bertem (relation 2).

Maybe we can put in the conventions:
relation 1 --> *bus 8*   Bertem-Leuven-Bierbeek
relation 2 --> *bus 8 ** Bierbeek - Leuven - Bertem



2010/8/10 Renaud MICHEL 
>

> Le mardi 10 août 2010 à 10:22, Tim Francois a écrit :
> > +1. Yup, this is what is currently happening in most of the UK - a
> > separate relation for the 'up' and 'down' bus routes, so that
> > forwards/backwards (which is kinda broken as a concept in this case)
> > is not required!
>
> I'm interested, for now I have created single relation for a bus route in
> Liège.
> How should I tag the two separate relations?
>
> The page
> http://wiki.openstreetmap.org/wiki/Buses
> doesn't talk about double relation, but suggests that bus_stop should be
> put
> on the way, but the bus stops are not on the road but along it.
>
> --
> Renaud Michel
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Ivo De Broeck
Valleilaan 13
3360  Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Maarten Deen
On Tue, 10 Aug 2010 10:41:38 +0200, Renaud MICHEL
 wrote:
> Le mardi 10 août 2010 à 10:22, Tim Francois a écrit :
>> +1. Yup, this is what is currently happening in most of the UK - a
>> separate relation for the 'up' and 'down' bus routes, so that
>> forwards/backwards (which is kinda broken as a concept in this case)
>> is not required!
> 
> I'm interested, for now I have created single relation for a bus route in 
> Liège.
> How should I tag the two separate relations?
> 
> The page
> http://wiki.openstreetmap.org/wiki/Buses
> doesn't talk about double relation, but suggests that bus_stop should be put 
> on the way, but the bus stops are not on the road but along it.

Have a look at http://wiki.openstreetmap.org/wiki/VRS , for a lot of
relations, there are two routes. Often also tagged with a from and to in
the relation, although I don't know if that really helps in a program.

Regards,
Maarten


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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Renaud MICHEL
Le mardi 10 août 2010 à 10:22, Tim Francois a écrit :
> +1. Yup, this is what is currently happening in most of the UK - a
> separate relation for the 'up' and 'down' bus routes, so that
> forwards/backwards (which is kinda broken as a concept in this case)
> is not required!

I'm interested, for now I have created single relation for a bus route in 
Liège.
How should I tag the two separate relations?

The page
http://wiki.openstreetmap.org/wiki/Buses
doesn't talk about double relation, but suggests that bus_stop should be put 
on the way, but the bus stops are not on the road but along it.

-- 
Renaud Michel

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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Ivo De Broeck
OK, can we put this in the conventions wiki pages?

Proposal:
Use two different relations, one for the "forward" direction, one for the
"backward" direction.
Example :
relation xx busnumber zzz Brussels - Antwerp
relation yy busnumber zzz Antwerp - Brussels


Op 10 augustus 2010 10:22 schreef Tim Francois  het
volgende:

> >> Een oplossing zou natuurlijk kunnen bestaan uit het maken van 2
> >> relaties :
> >> relatie x 8 Bertem -> Bierbeek
> >> relatie y 8 Bierbeek -> Bertem
>
> >Dat is wat op veel plaatsen toch al gedaan wordt. En dan geen forward
> >of backward er in. Ik zou zeggen: de eerste node/way in de relatie geeft
> >aan waar gestart wordt.
>
> +1. Yup, this is what is currently happening in most of the UK - a
> separate relation for the 'up' and 'down' bus routes, so that
> forwards/backwards (which is kinda broken as a concept in this case)
> is not required!
>
> Tim
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>

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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Tim Francois
>> Een oplossing zou natuurlijk kunnen bestaan uit het maken van 2
>> relaties :
>> relatie x 8 Bertem -> Bierbeek
>> relatie y 8 Bierbeek -> Bertem

>Dat is wat op veel plaatsen toch al gedaan wordt. En dan geen forward
>of backward er in. Ik zou zeggen: de eerste node/way in de relatie geeft
>aan waar gestart wordt.

+1. Yup, this is what is currently happening in most of the UK - a
separate relation for the 'up' and 'down' bus routes, so that
forwards/backwards (which is kinda broken as a concept in this case)
is not required!

Tim

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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Lennard
> Als ik het goed begrijp wordt forward/backward alleen gebruikt op
> gedeeltes van een route die maar in één richting gebruikt worden en waar

+1

> En dan krijg je weer verschillende stukken en de
> relation analyser.
> Alleen dat is al de reden dat ik geen fan van forward/backward ben.

Dat ligt meer aan die relation analyzer die dit niet goed visualiseert.
Dat doet niets af aan de geldigheid van de relatie.

> Dat is wat op veel plaatsen toch al gedaan wordt. En dan geen forward
> of backward er in. Ik zou zeggen: de eerste node/way in de relatie geeft
> aan waar gestart wordt.

Bij fietsroutes wordt er ook maar 1 relatie gebruikt voor beide
richtingen, indien de fietsroute ook over eenrichtingstukken leidt. Exact
hetzelfde principe als voor busroutes.

-- 
Lennard



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


Re: [OSM-talk-be] busroutes

2010-08-10 Thread Maarten Deen
On Tue, 10 Aug 2010 09:31:45 +0200, Ivo De Broeck
 wrote:
> Ik probeer stadsbus nr 8 in een relatie te gieten. Met backward en
> forward geeft de relatiechecker allemaal kleine stukjes. Is het
> mogelijk om bepaalde vakken zowel forward als backward te noemen en
> toch de relatie consistent te houden? 
> 
> Ik heb nu 1 richting volledig (forward) gemaakt voor het traject
> zie http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=1115027
> [1] en dat is ok. Als ik 1 stuk eruit, zowel forward als backward
> benoem (of blanco laat) is alles weer stuk. 

Als ik het goed begrijp wordt forward/backward alleen gebruikt op
gedeeltes van een route die maar in één richting gebruikt worden en waar
de tegenrichting dus over een andere weg rijdt. En wordt forward
gebruikt voor "in de richting van de way" en backward in de andere
richting. Dus als je een weg hebt die is opgebouwd als *>*<-*,
dan zal het eerste stuk als forward en het tweede stuk als backward
getagt moeten worden. En dan krijg je weer verschillende stukken en de
relation analyser.
Alleen dat is al de reden dat ik geen fan van forward/backward ben.

> Een oplossing zou natuurlijk kunnen bestaan uit het maken van 2
> relaties : 
> relatie x 8 Bertem -> Bierbeek 
> relatie y 8 Bierbeek -> Bertem

Dat is wat op veel plaatsen toch al gedaan wordt. En dan geen forward
of backward er in. Ik zou zeggen: de eerste node/way in de relatie geeft
aan waar gestart wordt.

Groeten,
Maarten

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