Re: [OSM-talk-be] Railway data accuracy , age and origin

[Ben Laenen]

On Wednesday 07 January 2015 18:00:53 Sander Deryckere wrote:
 Most of the railway data comes from survey, aerial images and knowledge (no
 imports, apart from Urbis, Brussels).
 
 The lines are usually mapped to the pair of rails (even showing the
 switches in most cases), and many lines have extra details s.a. gauge,
 voltage or maxspeed. But those are not rendered. Mapnik rendering does
 differ between major lines and service lines.

I'm in the process of reviewing (and for the most part redrawing) the entire 
rail network in Flanders (to begin with, if the aerial imagery of Wallonia is 
good enough, I may extend it a bit that way, I've done all of West-Flanders 
and most of East-Flanders so far. It has slowed a bit since I don't have a lot 
of free time at the moment, but I hope to continue soon. If you come across 
some loose ends, that's where I'm at. Sources are the AGIV imagery, but I have 
a bit more knowledge about it since I'm an actual train driver. I try to work 
as accurate as possible, but it's a huge task (and I still have to do the 
entire port of Antwerp, ugh)... In the process I'm also adding maxspeeds, 
proper line refs and station/yard/junction names and codes, so you get nice 
maps on 
http://www.openrailwaymap.org/?lang=enlat=51.02844005602989lon=3.49365234375zoom=9style=standard

On that aspect, I'm currently tagging everything except the industrial line as 
main line, and never branch line. Infrabel doesn't really make a distinction 
there, and I feel like creating one will just be too subjective. If someone 
has a better idea, let me know.


Greetings
Ben



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

Re: [OSM-talk-be] Validatie error railway:historic

[Ben Laenen]

On Wednesday 07 January 2015 20:33:41 Marc Gemis wrote:
 There are more strange things near the place that you linked:
 1) a cyclepath that is named Fietspad Jef Van Linden. I expect that this is
 actually a cycleroute with this name. Has to be verified with a survey.

No, that cycleway actually has that street name. There are street name signs 
with it, and it's in the official street name list of Antwerp

Ben


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

Re: [OSM-talk-be] Wandelknooppunten

[Ben Laenen]

On Thursday 14 May 2015 08:55:41 Guy Vanvuchelen wrote:
 In Frans Vlaanderen heb ik gedurende enkele dagen wandelknooppunten (Monts
 de Flandre – Heuvelland) genoteerd.
 
 Waar vind ik uitleg om de routes tussen twee punten te mappen? Is dat één
 relatie per route of komen alle routes in één relatie?

http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Walking_Routes#Walking_node_networks

Alle routes tussen twee knooppunten vormen een aparte relatie.

Om voorbeelden te zien, check ook 
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Walking_Routes
(wel geen idee hoe up to date die pagina tegenwoordig is)

Ben


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

Re: [OSM-talk] The Proposed Great Colour Shift

[Ben Laenen]

 For me, the new style is a pointless exercise since I NEED to retain a
 UK view of the data, and I am sure other countries would also prefer to
 retain their own road colour preferences so trying to provide an
 international style has a limited 'market'? If anything it simply drives
 us to provided more local styled services?

Isn't it possible to have separate UK rendering on the same map, like
on the Mapquest layer? If such a framework is created it could even
open up other renderings for different countries. Thing is that UK
won't ever be happy with another colour scheme and the rest of the
world won't ever be happy with a UK scheme.

Ben

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

Re: [OSM-talk-be] openpoimap voor verkeersborden in Belgie

[Ben Laenen]

On Wednesday 29 July 2015 22:31:55 Ruben Maes wrote:
 Hoe worden uitgezonderd bla bla bla-onderborden getagd? Ik heb er eentje
 traffic_sign=BE:C3,uitgezonderd bus en taxi, laden en lossen

Zoals ik al een tijdje geleden heb geopperd (en indertijd een eigen bescheiden 
poging heb ondernomen maar die niet ver geraakt is): als we verkeersborden 
gaan mappen moeten we eerst misschien eens samenzitten over hoe we dat juist 
gaan doen. Of een bord nu A3 is of F99a, dat is eenvoudig, maar het gaat om al 
die extra variabele info die op die verkeersborden staan, naar welke kant 
een pijl wijst, welke tekst of welk cijfer erop staat, of welke symbolen 
gebruikt worden en in welke volgorde. En last but not least ook een manier 
vinden om de oriëntatie van een bord te mappen (staat het bord rechts van de 
weg of links, of naar wie is het gericht als het op een middenberm staat).

Het zou leuk zijn moesten we weten hoe de Vlaamse verkeersbordendatabank het 
juist heeft aangepakt om wat ideetjes te kunnen oppikken (lees: stelen)...



Wat betreft de kaart van Marc: misschien moet je er de verkeersborden op een 
paal zetten zodat je duidelijk kan zien waar die exact staat (zodat de 
onderkant van de paal overeenkomt met de node in OSM).

mvg,
Ben


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

Re: [OSM-talk-be] Nummering bruggen

[Ben Laenen]

Tegenwoordig pas? Ik heb in de provincie Antwerpen nooit anders geweten dat 
die nummers eraan hingen (maar als ik me goed herinner in een erg oud topic 
daarover zou de rest van Vlaanderen daar niet aan meedoen?).


Wat betreft de planimetrische punten, was het probleem daar niet dat dat in 
een database zit van het NGI en dat die dus niet vrij kan worden gekopieerd? 
En dat je die punten dus in realiteit niet juist kan onderscheiden (het gaat 
soms om de top van een kerktoren, of de ijzeren dingetjes die je in de grond 
overal ziet eens je erop let dienden enkel voor lokale aanleg maar zijn geen 
planimetrische punten van het NGI).

mvg,
Ben



On Tuesday 13 October 2015 17:23:55 Philippe Casteleyn wrote:
> Er verschijnen tegenwoordig gele viercijferige borden met het embleem van
> een leeuw op bruggen.Vroeger was het "ministerie" erg schuw met het
> vrijgeven van de brugnummers.Misschien is er nu een goede nummering
> gekomen.Op hun website vind ik alvast niets.Ik dacht even dat er een
> altimetrisch punt bij hoorde, maar dat is natuurlijk absurd.  Niettemin is
> er geen overdaad aan publiek gekende gematerialiseerde
> verdichtingspunten.De brug :  
> http://www.openstreetmap.org/way/308898682Bord met hoogteaanduiding : 
> https://www.mapillary.com/map/im/UIxzuIzwZDx2FixwAQnEmQ/photoInstructieboek
> voor opmaak van plannen
> :http://wegenenverkeer.be/sites/awv/files/docs/Instructiebundel%20voor%20st
> udie-%20en%20landmeetbureaus%20versie%202014%20%201%200%20AWV%20_0.pdfZijn
> er nog mensen geïnteresseerd in planimetrische punten ? 
> https://www.mapillary.com/map/im/jyvs9YdE6LzPep0H-RhQOA/photohttp://www.ngi
> .be/gdoc/index.html?lang=nl=484878.74=6593757.54=20=ngi.c
> artoweb.topo_bw.be=alti_coord,plani_coord_visibility=false,tru
> e=openedIk gebruik moeilijke woorden in de hoop dat iemand ze mij
> uitlegt.Ph Casteleyn Dahliastraat 162800
> Mechelenanimals.slippers.loadersgsm 0486 516261Ctrl+v


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

Re: [OSM-talk-be] adressen

[Ben Laenen]

Ik denk niet dat er al iemand begonnen is met het systematisch mappen
van alle adressen in Antwerpen? De straten moeten er zo goed als
allemaal in zitten, in de beginjaren werd daarvoor vergeleken met de
straatnamenlijst die je online kan vinden. Maar adressen zelf is nog
een ander titanenwerkje (en al zeker als we gebouwen ook ineens willen
mappen), dus tegen wanneer dat in OSM staat daar durf ik alvast niets
over zeggen. Ten vroegste over een paar maanden, op voorwaarde
natuurlijk dat er iemand nu meteen aan begint (en het volhoudt tot het
eind), aangezien het volgens mij wel een werkje is waar iemand
fulltime wel enkele weken mee zoet zou zijn.

Als er interesse is misschien iets met een aantal mensen coördineren
om er eens werk van te maken?

Ben


2015-08-27 10:01 GMT+02:00 joost schouppe joost.schou...@gmail.com:
 Dag allen,

 Ik heb ontdekt dat onze geostatistische website voor Antwerpen sinds kort
 Openstreetmap gebruikt om te zoeken op adres (een van de knopjes rechtsboven
 als je een kaart in beeld hebt).
 Vroeger gebruikte die service de api van CRAB. Alvorens te vragen of ze
 alsjeblieft weer naar een volledig adressenbestand kunnen verwijzen, iemand
 off the top of their head een idee welk aandeel van de adressen in 't Stad
 nu al gemapped zijn en op welke termijn we volledig zouden kunnen zijn?

 Ik vermoed dat onze leverancier ervoor kiest omdat Nominatim sneller is, en
 gebiedsdekkend in hun werkingsgebied (Nederland en Vlaanderen). Maar
 openaddresses.io is ook gebiedsdekkend. Zou iemand daar al een open
 adreszoeker op gebouwd hebben?

 --
 Joost @
 Openstreetmap | Twitter | LinkedIn | Meetup | Reddit | Wordpress

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


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

Re: [OSM-talk-be] A12 motorway

[Ben Laenen]

Indeed, there's only one Belgian road number on a road, and for the
Antwerp Ring this is R1, not A1 which is completely wrong. If two
numbered roads join for a while before separating again, then only one
number is used for the shared part (as opposed to the Netherlands
where they can put multiple numbers on a road).

About the E-numbers, the Ring is part of some of them, although we're
in Belgium in this special situation where we're using E-numbers of
motorways as the main reference, but never use them on the R-roads. So
it's correct but a lot of people think it's odd that the Ring would be
labeled E19 and E34.


Ben


On Fri, Sep 4, 2015 at 1:51 PM, Gerard Vanderveken  wrote:
> Hi,
>
> I see thet the ring of Antwerp is incorporated in the relations of E19
> (Amsterdam - Paris) and of the A1 (Flemish part of A19).
> While the E-roads are a conceptual thing, this is understandable.
>
> However the A-roads are a physical, real highway and they should be mapped
> as indicated on eg. the km-markings.
> That means that the ring around a city is a separate way: the R-roads and
> not part of a A-road.
>
> For this reason I would suggest to leave the A12 in 2 pieces and recommend
> to remove the ring from the A1.
>
> In any case:
> - segment 3 is the end point of segment 6 and should be joined to it by
> adding it and the missing piece of road between.
> - same problem for segment 4 which should be joined to 6 with th missing
> bridge part.
>
> Regards,
> Gerard.
>
> Marc Gemis wrote:
>
> Hallo,
>
> I'm wondering whether the relation for the A12 should include the ringway in
> Antwerp as well.
> Right now, the relation consists of 2 separate sections, north and south of
> Antwerp.
> see http://osmrm.openstreetmap.de/relation.jsp?id=102684
>
> Depending on the answer to that question, I might remove what is marked as
> section 3, which is not connected to any other part.
>
> regards
>
> m
>
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Delete not marked walking routes?

[Ben Laenen]

We've had this discussion before, and you're representing the consensus: no
walking routes that aren't marked on the ground, and you should be able to
walk the route by following the marks or signs. Or we risk, as you say,
that everyone will just make their own routes, maybe put them on their own
website, and then copy it to OSM. Transport lines are something completely
different that don't apply here (and anyway, you can follow those routes
without any reference, just follow the bus, boat or whatever). Also, does
he even have permission to copy the routes from the books he's using? If
not, that's plain copyright infringement.

Greetings,
Ben


On Sat, Sep 5, 2015 at 11:51 PM, Erik Beerten  wrote:

> Hello,
>
> Since a few years I have meanly been busy with tagging (waymarked) walking
> routes. Recently I got annoyed because in the regions where I am active
> there are walking routes visible on www.waymarkedtrails.org
> 
> but without any sign on the ground (as (1)
>  & (2)
>  ).
> I contacted the taggers via remarks to their changesets. They confirmed
> that those routes are not marked on the ground but only described in a
> book. I argued that only marked routes should get in OSM because of the
> principles described in http://wiki.openstreetmap.org/wiki/Good_practice
> The relevant principles are 'Map what's on the ground' and 'Verifiability'.
> For this last principle 'essentially means another mapper should be able to
> come to the same place and collect the same data'. Verifiability has as
> consequence for non marked routes (only described in a book) that another
> mapper who checks a mapped route and doesn't find any marks, can only
> conclude that this route doesn't exist (anymore) and that it should be
> deleted in OSM.
> Gerdami, the mapper who did the route near Fumal (Liège) didn't agree and
> refers to buslines, trainline, airlines and maritime lines(see below) and
> therefore I want to put this issue to the community.
>
> Other arguments to leave routes not marked on the ground out of OSM
> besides 'Map what's on the ground' and 'Verifiability':
>
>- All tagged routes get in www.waymarkedtrails.org
>
>. If also not waymarked routes get in there then this application looses
>all value.
>Now you can have a look on this application or similar as
>hikebikemap.org, find a waymarked route, go to a place where it passes
>and follow the signs.
>- If walking routes described in a book (or just thought-out by
>whoever) can get in OSM, we risk that an enormous number of walking routes
>can get in OSM without any added value. Just imagine that all routes
>described in the hundreds of walking guides for Belgium, written by Julien
>van Remoortere or in Lannoo's walking guides or others, get in OSM. Tagging
>waymarked trails would loose all sense. A users can't  see any difference
>on the actual cards between a marked or unmarked route.
>- If walking routes only describe in a book are permitted then there
>should be a key is to make destinction between marked and unmarked routes
>to permit making cards as of waymarked trails.
>- The same is valid for biking and MTB routes. There are also lots of
>those that are only described in books or websites. What about the CycleMap
>layer of www.openstreetmap.org
> ?
>Include biking routes only described in books?
>-  Renderers as www.waymarkedtrails.org
>
>have no possibility to filter non marked trails to show only the waymarked
>trails. I wonder what they would find of permitting to add not marked
>trails?
>
> What to do?
>
> Regards,
>
> Erik
>
>  Doorgestuurd bericht  Onderwerp: [OpenStreetMap] gerdami
> heeft gereageerd op een wijzigingenset waar u interesse in hebt Datum: Fri,
> 04 Sep 2015 19:21:49 + Van: OpenStreetMap
>   Aan:
> ebe...@gmail.com Hallo,
>
> gerdami heeft gereageerd op een wijzigingenset die u volgt die gemaakt is
> door gerdami op 2015-09-04 19:21:49 UTC met reactie "Eglise de Latinne"
> ==
>
> Dear Eebie,
> You have a restrictive reading of the guidelines, which by the way are
> guidelines, not rules.
> The guidelines do not say anything about relations, which are logical by
> definition.
> If we were to follow your restrictive view, one would have to delete all
> maritime lines because they could not be verified on the ground. Bus lines
> should be removed as well because, unlike railways, there are no physical
> markings on the roads, a part bus stops. International bus lines such as
> Eurolines could not be 

Re: [OSM-talk-be] GRB Flanders

[Ben Laenen]

Ik maak me ook het meeste zorgen om de schaal van zo'n importoperatie. We 
kunnen nu al zien met CRAB (wat uiteindelijk quasi manueel toevoegen van elk 
adres is) dat het jaren duurt vooraleer het kleine groepje vrijwilligers daar 
ooit helemaal is doorgeworsteld, dat ik me afvraag hoe we dat met een nog 
grotere dataset gaan aanpakken. We kunnen ook moeilijk al de bestaande data 
gewoon gaan overschrijven. Als er al data bestaat moet je de twee gaan 
vergelijken en laat dat nu nog veel meer werk en tijd kosten.

En de import is één ding, het up to date houden wordt nog een veel groter 
probleem... Misschien ook eens raad vragen aan onze Nederlandse collega's die 
toch gelijkaardige grote imports hebben gedaan (al was het bij hen wel véél 
vroeger in het project toen de hoeveelheid data nog aanzienlijk minder was dan 
wat wij nu in België hebben gemapt op de "oude" manier).

Ben


On Tuesday 29 September 2015 20:26:07 Pieter Colpaert wrote:
> Hi all,
> 
> The GRB (https://www.agiv.be/producten/grb) will become open data
> starting January, probably under the free open data license Flanders.
> 
> What are the obstructions/possibilities to start using this in OSM?
> 
> Kind regards,
> 
> Pieter


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

Re: [OSM-talk-be] Rise of the voetwegen

[Ben Laenen]

On Wednesday 02 December 2015 14:10:45 Glenn Plas wrote:
> > Wat de naam betreft kies ik eerder voor een alternatieve tag die ik
> > indertijd ook al enkele keren heb gebruikt in de buurt van Antwerpen,
> > namelijk vicinal_ref=* en vicinal_type=path/road
> 
> Die kende ik niet, maar zet je dan de naam in de ref of zo ?

'k Had het ook zelf uitgevonden om het te kunnen taggen. Zie bijvoorbeeld deze 
wegen in Wommelgem http://www.openstreetmap.org/#map=16/51.2037/4.5200 waar ik 
indertijd het meeste werk heb gedaan voor de buurtwegen.

Op deze manier kan je alle straten ook hun juiste buurtwegennummer geven 
zonder dat je alt_name hoeft te plaatsen op gewone straten. En "Voetweg X" 
vind ik ook gewoon niet thuishoren in een *_name=* tag.

Ben


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

Re: [OSM-talk-be] Rise of the voetwegen

[Ben Laenen]

On Wednesday 02 December 2015 14:35:12 Glenn Plas wrote:
> Volgens mij kan je de gewone ref ervoor gebruiken ipv een nieuwe uit te
> vinden (wat indertijd wss wel goed idee was, we kunnen via OverPass
> gemakkelijk al die voetwegen van Ben terugvinden nu.  Het is een kwestie
> van hier een consensus te kunnen bereiken zodat we consequent gaan mappen.

Wat mij betreft liefst geen gebruik maken van de gewone ref=*. Al die 
gewestwegen met ref=N123-nummers hebben namelijk meestal ook buurtwegnummers, 
wat ga je dan doen?

Ben


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

Re: [OSM-talk-be] Rise of the voetwegen

[Ben Laenen]

Iemand die de Atlas der Buurtwegen aan het kopiëren is?

> Ik vind dat een 'path' meer geschikt is, zeker als ik de voetweg door
> velden zie gaan en waar een geen visible pad is volgens AGIV sat pics.
> 
> Iemand daar zelf ook al issue's mee gehad.  Is er iemand die 'footway'
> meer geschikt vind voor vaak -kwasi denkbeeldige- wegen?  Waarom?

Ik vind nog steeds dat je het pad of de weg in realiteit moet kunnen zien. Ik 
weet dat die paden in principe nog moeten bestaan als ze niet uit de Atlas 
zijn gehaald maar we moeten de gebruikers ook geen verkeerde verwachtingen 
moeten geven. Laat het forceren van verdwenen paden maar over aan andere 
belangengroepen... En als er in de praktijk geen auto kan of mag rijden ook al 
is het een buurtweg officieel, dan map je het inderdaad met path of footway, 
naargelang de situatie.

> Ik pas dit meestal in alt_name='voetweg 1234' en dan als
> name='Liposuctievoetweg'.

Wat de naam betreft kies ik eerder voor een alternatieve tag die ik indertijd 
ook al enkele keren heb gebruikt in de buurt van Antwerpen, namelijk 
vicinal_ref=* en vicinal_type=path/road

Ben


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

Re: [OSM-talk-be] tagging conventions

[Ben Laenen]

I'm sure you can look through this mailing list's history and find all kinds of 
discussion about it in the past...

Long story short: the unpaved thing was more or less the original usage, then 
it was changed in some other countries which was set as the international 
definition and in Belgium we didn't change it.

Personally I think the difference unpaved <-> paved for track <-> other road 
types makes much more sense in Belgium, and also much more objective.

Ben


On Tuesday 22 December 2015 08:37:35 joost schouppe wrote:
> Hi all,
> 
> I was looking at this page:
> http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
> 
> And I saw only unpaved roads are supposed to be tagged as track. I've been
> seeing quite a few rural roads which only allow agricultural vehicles and
> only lead to fields. They look to me essentially as paved tracks. In most
> of the world (i.e. outside of Europe) what the road is used for trumps road
> quality when it comes to classification.
> 
> Shouldn't this "Unpaved roads with traces of motor traffic or accessible to
> motor traffic" be replaced by something like "Paths which show use of
> occasional motor traffic, or are designed to do so and that don't prohibit
> such use. Generally unpaved and used to access forests or agricultural
> fields."


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

[OSM-talk-be] Bewegwijzerde fietssnelwegen

[Ben Laenen]

http://deredactie.be/polopoly_fs/1.2669657!file/Brochure_Fietssnelwegen.pdf

Nu ze de fietssnelwegen hun nummers geven en ermee gaan bewegwijzeren: hebben 
we nog netwerktags over om deze routes nog hun eigen plaatsje te geven?

mvg,
Ben


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

Re: [OSM-talk-be] University tagging

[Ben Laenen]

On Thursday 21 January 2016 12:55:25 Ben Laenen wrote:
> But I may very well be wrong, when I saw the threads on this list I did a
> little bit of googling, and that's what I came up with.

After some more googling, this site has a perfect overview of all the levels 
in Flanders:

http://vlaamsekwalificatiestructuur.be/wat-is-vks/kwalificatieniveaus/

Ben


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

Re: [OSM-talk-be] University tagging

[Ben Laenen]

On Thursday 21 January 2016 12:38:43 Ruben Maes wrote:
> (...)
>
> As I understand it, the ISCED levels are as follows for Flanders:

I think I understand it differently then :-)


> (...)
> 
> Secundair onderwijs
> 2 1e-3e middelbaar (Lower secondary education)
> 3 4e-6e middelbaar (Upper secondary education)
> 4 Specialisatie BSO (Post-secondary non-tertiary education)

I think this one is more difficult, with 2 being first two years of secondary, 
3 
the third and fourth year, and 4 the full ASO or TSO.

> Hogeschool
> 5 Professionele bachelor (Short-cycle tertiary education)

Do these have their own group? I thought 5 was something for HBO5, and the 
"hogescholen" go into the same bachelor and master groups of 6 and 7...


> Universiteit
> 6 Academische bachelor (Bachelor or equivalent)
> 7 Master (Master or equivalent)
> 8 Doctoraat (Doctoral or equivalent)

But I may very well be wrong, when I saw the threads on this list I did a 
little bit of googling, and that's what I came up with.

But these are the numbers that Flanders gives to them, they don't translate 
one to one to the international numbers...

Ben


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

Re: [OSM-talk-be] Bicycle highways

[Ben Laenen]

On Sunday 24 January 2016 22:38:06 Sander Deryckere wrote:
> I think we should get away from those rcn, lcn and ncn networks. And be
> freer in the allowed networks.
> 
> Even now there are problems with rcn networks used for cycle nodes, as
> those are getting introduced in France and Germany, while those countries
> already use those networks for other route types.

I agree the network tags should be rethought a little bit. We had some issues 
years ago when in Antwerp they created a small network of cycle routes through 
the city, not touristic routes, but fast safe routes. These routes were at the 
time signed with markings on the ground, but have since disappeared. But now I 
think about it, I think Brussels still has similar signed routes?

So all those networks are clashing with each other. At the very least we'll 
need to start making a distinction between touristic routes and functional 
routes (routes to actually go somewhere). I still like the hierarchy between 
local, regional and national (and international), but we need one set of those 
for touristic routes and one for functional routes. The Brussels network could 
then be one of those local ones, the bicycle highways regional.

Ben


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

Re: [OSM-talk-be] Beginning with survey new "Fietsknooppunten West-Vlaanderen"

[Ben Laenen]

On Friday 11 March 2016 10:59:56 Jakka wrote:
> [...]
> The new node 85 over the bridge to north is also divided to avoid
> crossing roads.
> 
> These examples are with two mean node of same number. I thing there will
> be others with more node of the same mean node...
> 
> Thinking the new network has a lot of security measures with multi fork
> nodes with same number.And those will not close together.
> 
> How do we deal with this.

This has been long solved: tag those multiple nodes with their normal number 
(e.g. "07"), and from each node, create relations to the nodes they connect to 
using forward/backward roles on the ways.

There's an example at 
http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging#Split_nodes_and_the_tentacles_extending_the_routes_to_connect_them

Greetings,
Ben


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

Re: [OSM-talk-be] Temporary Blocker roads

[Ben Laenen]

On Tuesday 05 April 2016 12:12:15 Marc Gemis wrote:
> I'll probably do it (access=no) for the "fietsbrug" near Rumst, since
> it will be closed from May to Sep.
> I'll place a reminder in my agenda to go check it and update it in
> September.

We need some proper international rules for those temporary closures, and 
better tags that are actually supported. The problem now is that you for 
example put an access=no on a road that's closed for a month, and during that 
month someone else makes a dump of the data and now that dump will have an 
inaccessible road until a new dump is made, maybe several months later. Or 
worse, someone forgets to remove the tags when the road has opened again and 
then it stays like that until someone happens upon it.

Personally I refrain from tagging temporarily blocked roads unless it takes 
longer than half a year or so. But a proper solution should really come from 
the international community if we want something that's supported across 
different applications.

Ben


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

Re: [OSM-talk-be] State of the Map Brussels taking shape

[Ben Laenen]

On Tuesday 03 May 2016 10:09:07 Glenn Plas wrote:
> Hey Jo,
> 
> Community tickets are 75 euro, and we indeed need them, even if you come
> to help, which makes kind of sense to me since about everyone there
> minus 10% will be a contributor in the broad sense of the word.

Yeah, but what about volunteers during the event? People who spend their time 
at SotM doing work instead of being able to watch the talks? Who's going to 
pay 75 euro for the privilege of basically working several days?

Ben


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

Re: [OSM-talk-be] OSM in French and Dutch

[Ben Laenen]

On Tuesday 09 August 2016 11:37:58 joost schouppe wrote:
> Someone asked on Twitter about a rendering of OSM in Dutch and French to
> avoid the clutter of bilingual names in the standard rendering.

How about this one: http://mlm.jochentopf.com/

Fill in "nl" or "fr" in the box to get the names rendered in those languages

Ben


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

Re: [OSM-talk-be] Wat mappen in Brussel (was Re: Bulk import, mogelijkheden?)

[Ben Laenen]

On Tuesday, 31 January 2017 07:53:57 CET Marc Gemis wrote:
> Is het niet vreemd dat we de snelheid voor auto's wel mappen, maar die
> voor vrachtwagens niet ?

Mogen vrachtwagens niet sowieso maximum 90 km/u in België en is de 
maximumsnelheid dan geen eigenschap van het voertuig en niet van de weg?

Ben


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

Re: [OSM-talk-be] Wat mappen in Brussel (was Re: Bulk import, mogelijkheden?)

[Ben Laenen]

On Tuesday, 31 January 2017 13:14:37 CET Glenn Plas wrote:
> >> Neen, bvb op het viaduct van Vilvoorde mogen personenwagens 90 km/u en
> >> vrachtwagens slechts 70 km/h.
> > 
> > Maar daar staan dan altijd extra verkeersborden, die we uiteraard wel
> > mappen.
> Ik zou die wel eens graag willen zien, volgens mij zit in OSM bijna
> niets als het gaat over locale snelheidsbeperkingen voor een bepaalde
> manier van transport, buiten de wagen om.  Bitter weinig aanwezig.
> idealistisch gezien mappen we idd we de verkeersborden, maar in de
> praktijk zijn ze amper gemapt.

Of ze in OSM zitten is een andere vraag, maar een extra snelheidsbord met 
daaronder een onderbord zoals "+3.5t" (of "+7.5t" of dergelijke) bestaat wel 
meer in dit land.

En dit staat er op het viaduct in Vilvoorde:
https://www.mapillary.com/map/im/8RahppbFJDuIl2_dI51kgA


> > En die 70 daar is niet enkel voor vrachtwagens, maar alles boven 3.5 ton
> > (als ik me goed herinner).
> 
> Vind ik niet echt relevant, het punt is dat voor bepaalde voertuigen
> andere regels gelden.

Ik denk dat ik niet echt duidelijk heb gemaakt wat ik wou zeggen.

Het punt is dat sommige voertuigen sowieso niet sneller mogen dan een bepaalde 
snelheid in dit land, en dat je die extra beperking niet overal moet gaan 
mappen op plaatsen waar de normale snelheid toevallig hoger ligt.

Maar als ervan wordt afgeweken naar lagere snelheden zoals het viaduct in 
Vilvoorde dan moeten die uiteraard wel gemapt worden.

Wat ik niet wil is dat heel het land binnenkort volledig wordt gemapt met een 
extra "maxspeed:goods:conditional=90 @ (weight>3.5)" (of wat het wettelijk ook 
juist is) op de plaatsen waar geen extra verkeersborden staan. Een bromfietser 
klasse B mag ook maar maximum 45 en dat gaan we ook niet op elke weg in het 
land zetten.

Ben


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

Re: [OSM-talk-be] Bulk import, mogelijkheden?

[Ben Laenen]

On Sunday, 29 January 2017 14:05:32 CET Mars v. wrote:
> Wij hebben een grote hoeveelheid aanpassingen verzameld voor wandelpaden in
> Brussel en zoeken een manier om dit zo optimaal en naar mate mogelijk
> automatisch te importeren.

De eerste vraag vooraleer we iets van een goed antwoord kunnen geven is: wat 
zou je willen importeren? Wat zit er exact in de dataset?

Ben


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

Re: [OSM-talk-be] GRB hackday december 11th

[Ben Laenen]

On Tuesday 06 December 2016 17:21:24 joost schouppe wrote:
> The only downside is that the nearby trainstation of Bordet doesn't have
> trains in the weekend. So the most convenient way to get there, might
> actually be to take a Villo. That's actually quite simple, you can do it
> with a regular bank card. Or from Brussel Noord, take tram 55 to Da Vinci.
> Here's a little map to help you find the way [2].

On December 11 Bordet will get trains in the weekend again. It's not a 
convenient connection for those coming from the main Brussels railway stations 
(it's an hourly connection between Braine-L'Alleud and Leuven), but if you're 
coming from Leuven, then the train is certainly an option.

Ben


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

Re: [OSM-talk-be] Groen in de steden

[Ben Laenen]

On Friday, 13 January 2017 13:24:39 CET Jasper Michels wrote:
> Momenteel gebruik ik hier: Landuse=forest
> Maar volgens de wiki is dit enkel voor echte bossen.

But, but, but... 
http://www.gva.be/cnt/dmf20160628_02360973/italielei-en-amerikalei-zijn-volgens-joke-schauvliege-bos
 :-(

;-)
Ben


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

Re: [OSM-talk-be] Fwd: [OSM-talk] Upcoming removal of landuse=farm in the standard style

[Ben Laenen]

On Friday, 24 March 2017 15:43:47 CET Marc Gemis wrote:
> That's what some want to do in The Netherlands, a mechanical edit from
> farm to farmland.

That's what I would do. Yes, mechanical edits are bad, but a lot of the 
landuse data isn't really that accurate to begin with and would need 
improvement anyway, especially when landuse=farm has been used, so that we can 
safely replace it.

Ben


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

Re: [OSM-talk-be] Multilingual names

[Ben Laenen]

On Friday, 7 April 2017 11:28:32 CEST Marc Gemis wrote:
> I just stumbled upon the wiki page
> https://wiki.openstreetmap.org/wiki/Multilingual_names#Brussels
> I was surprised to read e.g. "Note that the "first mapper rule" is
> deprecated now." and "In OSM, we have a consensus to use a fixed
> order" (both changes made by Gplv2 on Oct 19, 2016)
> 
> Not that I care about the order of French and Dutch on those
> streetnames, but it would be nice to inform the community about such
> an important change via the mailing list, not ? If this is indeed the
> consensus I would have violated it since I did not know deprecation of
> the first mapper rule.
> 
> I asked Gplv2 to point me to the discussion leading to the consensus.
> 
> So I have no problems with this being the consensus, I do have a
> problem that such an important change is made without informing the
> mailing list.

There was a small talk about it around that time in the thread "Some 
information about Nominatim for addresses in Brussels" on this mailing list.

But there was no real discussion to change it, and certainly no consensus.

Ben


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

Re: [OSM-talk-be] Speed pedelec

[Ben Laenen]

On Friday, 21 July 2017 13:34:12 CEST Jakka wrote:
> Question on osm.org note:
> http://www.openstreetmap.org/note/1072935#map=18/51.15817/4.50524=N
> 
> How tag interdiction of speed pedelec ?

We're already using moped_A and moped_B in Belgium, we can easily introduce 
moped_P since they're classified as mopeds class P

Ben


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

Re: [OSM-talk-be] Mappen van spoorweginfrastructuur

[Ben Laenen]

On Saturday, 23 June 2018 19:12:22 CEST Ruben wrote:
> Er zijn veel verschillende soorten seinen, en dat verschilt dan ook nog eens
> per land. Eimai is begonnen aan een schema voor de Belgische seinen (
> https://wiki.openstreetmap.org/wiki/User:Eimai/Railway ), maar het sluit
> niet zo goed aan bij de internationale standaarden daarrond. In Duitsland
> staan ze daar veel verder mee. Er zijn er daar ook al heel veel gemapt, in
> België nog zo goed als geen.

Ik was er eens mee begonnen, maar het is zoveel werk, en veel van de 
informatie kan je ook niet aflezen van zo'n sein, dan moet je de officiële 
plannen al bekijken, of dus al treinbestuurder zijn dat je het gewoon weet.

Internationale standaarden zijn erg moeilijk in de spoorwegwereld, er zijn 
terugkerende elementen in alle landen (algemeen bijvoorbeeld: seinen die 
kunnen opleggen om te stoppen, seinen die iets zeggen over het volgende 
sein...), maar de reglementeringen en seinstelsels zijn vaak zo verschillend 
dat het erg moeilijk is om gemeenschappelijke grond te vinden, en wat de 
Duitsers hebben gemaakt van taggingschema is gewoon op zijn Duits. Echt niet 
triviaal om daar Belgische reglementering in te passen. Een regime kennen ze 
daar niet, van grote en kleine beweging ook niet, en dat zijn al de 
basisbegrippen in België.

Dat gezegd zijnde, zelfs al hebben we ooit een taggingschema uitgewerkt, het 
is erg veel werk om die dingen te mappen, en ik ben er niet echt van overtuigd 
of het al dat werk waard is. Als treinbestuurder zou ik het leuk vinden 
natuurlijk, maar het is niet alsof we met die informatie veel kunnen/mogen 
doen tijdens het rijden...

Ben




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

Re: [OSM-talk-be] Mappen van spoorweginfrastructuur

[Ben Laenen]

On Saturday, 30 June 2018 08:24:30 CEST Wouter Hamelinck wrote:
> 1. Dat is niet "de wiki", maar de individuele pagina van 1 enkele (erg
> geapprecieerde) gebruiker

Er zijn toen zoveel discussies over geweest dat ik het ergens heb geprobeerd 
toen van eens een lijn te zetten zodat er minstens consequent gemapt werd, 
niet dat je 10 mappers een situatie laat mappen en je 10 verschillende 
resultaten krijgt. Daar kan je als gebruiker niks mee aanvangen, want wat 
betekenen bepaalde tags dan in OSM? Wat ik toen heb geschreven is zeker niet 
ideaal, maar in elk geval wel al om iets te hebben om dan later als er meer 
eensgezindheid is vanuit verder te vertrekken. Van de internationale community 
kwam ook niet welke richting moet uitgegaan worden, mappen we het fysieke ding 
of houden we rekening met het gebruik ervan, de meningen zijn verdeeld. Ik heb 
in mijn poging dan zoveel mogelijk het gebruik in rekening gehouden om de 
access tags (waar het dan hoofdzakelijk om te doen was) zo eenvoudig mogelijk 
te hebben, maar dat bleef uiteraard allemaal mijn voorstel. Ik heb veel van 
die pagina's geschreven in de poging , maar ik ben ook maar ik dus niemand 
moet zich aan die dingen houden :-)

mvg
Ben




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

Re: [OSM-talk-be] railways and stations

[Ben Laenen]

Your message was directly sent to my spam box for some reason...

On Saturday, 20 January 2018 14:27:39 CET Stijn Rombauts wrote:
> Hi,
>
> I am rewriting the conventions page about railways [1]. It was a bit
> outdated...A few questions:- I kept the convention about the name ("L"
> followed by the number of the line, e.g. L25). But I noticed it hasn't been
> followed in many places (often 25 or L.25).

That's a small issue, our railways don't use the same convention everywhere, 
and you can find both L.25 and L25. When I started redrawing the railways in 
Belgium I ended up using L.25, whereas I've now started to think that ref=L25 
is the better option, and would fit in more with the other refs being used on 
junctions etc.

We just need to decide on one and keep using that. I'd now vote on L25.

> Do we keep this convention or
> not? The HSL/LGV lines have been given other names like "Ligne Nouvelle 1"
> or "LGV 3 - HSL 3". What do we do these?

The names shouldn't really be there, but I guess they don't do much harm. 
Their refs are ref=L.1 or L1 etc, no HSL or LGV in ref numbers.

> - The relations usually have a
> ref=L.25. (with the point). Still OK?

Same answer as above.

> - Some switches/junctions have a name
> (e.g. Y Val-Benoit) and are tagged as railway=junction. But this page [2]
> seems to suggest that railway=switch is a better tag. Or do we keep the
> railway=junction tag for named switches/junctions?

railway=junction is for a single node somewhere near the area where one or 
more switches are located. Their name should be something like 
name=Y.Abeelstraat (with a dot there), their reference is for example 
ref=YABLS without a dot.

railway=switch is for one single switch, they've got no names, only a 
reference, like ref=05AM.


> - Railway stations: I
> guess we're supposed to follow the rules/guidelines in this page [3]? Or do
> we have other opinions? E.g. in Visé [4] the tag railway=station has been
> used 3 times...

There should only be a single node tagged as railway=station.


> - Do we keep the distinction between railway=station and
> railway=halt. As more and more stations (=buildings) are closed, it seems
> to me that the distinction between the two has become quite vague.

There are a lot of definitions going around. In the railway definition a 
station would need a switch and allow a train to depart from. That would make 
Brussels-Central not a station... But in the end it's just better to tag them 
all railway=station.

Ben


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

Re: [OSM-talk-be] Update Slow Roads conventions Belgium

[Ben Laenen]

One question I have: why are the words "chemin", "sentier", "voetweg" etc.
part of the vicinal_ref tag? Better just leave the number in there, the
type of road is in the vicinal_type tag.

Ben

On Sat, 15 Dec 2018, 12:33 Steven Clays  Hello,
>
> I made a slight overhaul of the slow roads Belgium page, based on the
> discussion of Friday December 14th. A new tagging scheme is also proposed,
> seperating vicinal_ref and oficial_vicinal_ref. Links are restored and some
> pictures added. Comments and improvements welcome.
> https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Belgium/Conventions/Slowroads=1#Trage_wegen_Inventory
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Update Slow Roads conventions Belgium

[Ben Laenen]

On Sat, 15 Dec 2018, 14:59 Marc Gemis  I suggested that, as I think it is an part of the ref. We do map "E19"
> as well, not just 19.
> I want to be able te reconstruct the sign as I see it during a survey.
>


Yeah but those words aren't very consistent in usage, do you take the
French words for Flemish roads because the Atlas was made in French for
that municipality? In the end there are only two types, a path and a road,
and there's no difference in a path being a sentier, pad, voetpad or
voetweg on one map from the 1800s.

Also, if you want what's on the map, you'd need to have "Sentier n° 117" as
well for example.

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

Re: [OSM-talk-nl] Fietsknooppunten en naamgeving

[Ben Laenen]

On Saturday 27 September 2008, René Affourtit wrote:
  Over het verschil in B en NL tagging, moeten we inderdaad eens
  overleggen.

 Beide mee eens

Allé, goed dat ik me net heb ingeschreven op talk-nl dan :-)

't Is heel eenvoudig: de route heeft geen naam, dus heeft het geen zin 
om een name=* tag toe te voegen. 't Zijn de knooppunten die een naam 
(lees nummer, dus rcn_ref=*) hebben.

Daarentegen behoort de route en een knooppunt wel tot een netwerk (of 
twee op de grenzen), al is het niet altijd even duidelijk hier in 
België en kom je gerust knooppunten zonder netwerknaam tegen in de 
tussengebieden. Behoren tot een netwerk moet dan vertaald worden met 
iets als network_name=*.

Maar om overbodige data te weren zou de betere oplossing een relatie 
boven routerelaties en knooppuntnodes zijn, zoiets wat bijvoorbeeld de 
Europese wegenrelatie is: 
http://www.openstreetmap.org/browse/relation/20645 . Dan kan eenzelfde 
route of knooppunt tot twee netwerken behoren en moet je niet steeds 
die naam intikken.

De exacte syntax van die netwerkrelatie laat ik maar voorlopig als 
oefening...


 Knooppunt namen toevoegen kan ik me wel in vinden. Relatie-namen
 moeten in mijn ogen behouden blijven (al was het alleen al om in josm
 een overzicht te houden),

Nu taggen we niet meer voor de renderers maar ook al voor de editors :-)

Akkoord, 't is wat makkelijker in JOSM misschien met een naam, maar dat 
de editors dan worden aangepast dat ze een speciale tag lezen hé. In 
België zetten we de route als 15-85 gewoonlijk in de note=* tag. Het is 
al voorgesteld erg lang geleden aan JOSM en Potlatch mensen om de note 
tag weer te geven bij gebrek aan naam of ref tag, maar is wel steeds 
zonder gehoor gebleven (denk ik toch voor JOSM, heb het al een tijdje 
niet meer gecontroleerd).

Ben

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

Re: [OSM-talk-nl] Beschikbaarheid Flyer

[Ben Laenen]

On Wednesday 08 October 2008, Lennard wrote:
 Floris Looijesteijn wrote:
  ja dat was ik, er zijn er nog heel veel over.
  je kunt een stapeltje ophalen in amsterdam of leiden, schikt dat?
  maar welke mapping party heb je het dan over? ik zie nog niks op de
  wiki...

 http://wiki.openstreetmap.org/index.php/WikiProject_Belgium/Activitie
s#Mappingparty_Hoboken

 In Antwerpen.

Is het niet beter een Belgische versie te maken eerst? Met Belgische 
kaartjes en zonder www.openstreetmap.nl in het groot erop? :-)

Ben

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

Re: [OSM-talk-nl] amenity=college

[Ben Laenen]

On Monday 24 November 2008, Freek wrote:
 Ik bladerde net door Name_finder:Translations heen op de wiki, en zag
 daar College (amenity=college) tertiary education, not university
 college staan en vroeg me af hoe dat te vertalen.

Te laat, want ik heb alles al naar het Nederlands vertaald :-) (*)

Mij is altijd gezegd (en discussie met Engelstaligen heeft het al 
bevestigd) dat college in het Engels gelijk staat met hogeschool 
(tenminste toch hier in België, en dat is waar je naartoe gaat vanaf 18 
jaar, als je geen universiteit doet). Verwarrend omdat college in het 
Nederlands gebruik wordt voor een middelbare school (voor 12-18 
jarigen, ik heb nooit de afkortingen van Nederland proberen te 
begrijpen daaromtrend).

Ben

(*) = behalve dan het Engelse café, wat niet hetzelfde is als wat wij 
in het Nederlands café noemen. Maar ik weet niet welke vertaling dan 
wel beter zou zijn.

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

Re: [OSM-talk-nl] amenity=college

[Ben Laenen]

On Monday 24 November 2008, Freek wrote:
 Blijkbaar is MBO in Vlaanderen technisch secundair onderwijs (TSO)
 [1] (voornamelijk derde graad)

TSO is wel voor het gehele secundair, niet enkel de derde graad.

 en valt dit ook onder de term 
 college in het Engels, maar niet onder de term hogeschool in het
 Nederlands.

Blijkbaar worden die ook college genoemd 
http://en.wikipedia.org/wiki/City_Technology_College
maar ik weet niet hoe dat gebruik is in OSM. Dat kan je beter aan mensen 
in Engeland vragen :-) Maar als je de pagina leest zijn van alle 15 
city technology colleges al 12 academies geworden nu.

Maar naar mijn gevoel is college toch voornamelijk voor het tertiair 
(wat in België dus hogeschool is)

 Een eenduidige vertaling (voor de name finder) is er denk ik niet,
 maar het lijkt me wel handig om de omschrijving (voor map features)
 duidelijk te krijgen. Ik zou iets zeggen als Instituut voor hoger of
 middelbaar beroepsonderwijs (Nederland) of hogeschool (Vlaanderen),
 omdat MBO in Vlaanderen niet aan een aparte instelling gegeven wordt
 (of zijn er wel scholen die alleen derde-graads onderwijs
 aanbieden?).

Ik heb alleszins geen weet van dergelijke scholen.

Maar omdat er maar 3 middelbare scholen zijn die in het Engels college 
denk ik best dat je daar geen rekening mee houdt en die MBO's ook 
gewoon met school tagt.

Ben

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

Re: [OSM-talk-nl] amenity=college

[Ben Laenen]

On Monday 24 November 2008, Freek wrote:
 On Monday 24 November 2008, Roeland Douma wrote:
  Misschien is het sowieso een idee om een extra tag toe te voegen.
  Waarmee we aan kunnen geven of iets een MBO/HBO/... is, middelbare
  school (VMBO/HAVO/VWO/)
 
  Altijd weer leuk voor thema kaartjes.

 Ja, aan zoiets zat ik ook te denken. Desnoods moet het maar
 land-specifiek als er verder niks aan te doen is. Voorstellen?

 Zo internationaal mogelijk zou ik denken aan
 - school=primary:   basisschool
 - school=secondary: middelbare school
 - school=tertiary:  MBO/HBO/universiteit (maar voor die laatste is
 dat gewoon by default)

Der heeft iemand eens een begin gemaakt voor zoiets 
http://wiki.openstreetmap.org/wiki/Proposed_features/School_levels
maar 't heeft precies nog wat werk nodig...

Naast die level hebben we misschien ook nog een type nodig die dan 
gedefinieerd zijn volgens het land (zoals Nederlands VMBO, HAVO, VWO en 
de Belgische ASO, TSO, BSO, KSO), omdat die toch enkel in één land 
betekenis hebben. Alleen moeten we rekening houden met het feit dat een 
school niet noodzakelijk één type heeft.

Ben

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

Re: [OSM-talk-nl] Fietspaden kots

[Ben Laenen]

On Saturday 27 December 2008, Lambertus wrote:
 Ik heb zelfs voorbeelden gezien in Duitsland waar 
 alle voetpaden langs de wegen in kaart zijn gebracht.

Inderdaad, en zag dat er eventjes lelijk uit :-)

Alle gekheid op een stokje: trottoirs moeten echt niet via een way 
worden ingegeven, want daar is nu echt niets bij dat je aan extra 
informatie wint als je het doet met een way i.p.v. één of meer tags op 
de weg.

 Meer mapping 
 kan dus juist meer en beter informatie opleveren! Het feit dat de
 fietspaden (nog) niet goed aan de wegen zijn gekoppeld mag je naar
 mijn mening niet gebruiken om het concept van mappen van fietspaden
 langs wegen af te keuren.

Bah, improviseer een street-relatie. Die wordt al vaak gebruikt:
  type=street
  name=Naamstraat
en voeg alles van die weg daaraan toe. Kan je eventueel ook alle POI's 
op die weg aan toevoegen.

Alleen ga je mij vrijwel nooit aparte fietspaden zien tekenen, en dan 
hoofdzakelijk omdat het datamodel dat wegen worden bepaald door 
lineaire ways het maken dat je vaak zo'n verwrongen representatie van 
de werkelijkheid moet invoeren in OSM (en dan vooral aan kruispunten 
waar je rare kronkels moet verzinnen soms om alles aan elkaar te 
sluiten, tenzij je alles recht op recht houdt zodat je bij eventuele 
bus-, fiets- en wat-weet-ik-nog-allemaalroutes over dergelijke 
kruispunten al makkelijk 20 verschillende stukjes way kan krijgen omdat 
je voor die routes alles moet splitsen (*)) dat het ook niet meer mooi 
is. Al begrijp ik ook dat het ideale tweedimensionaal invoeren van 
wegen (dus straten als oppervlakken in plaats van lijnen) ook niet 
direct voor morgen is...

Een ander probleem met alle aparte fietspaden is dat je access regels zo 
goed als zeker niet meer kloppen (lees: geen bicycle=no, op de weg 
zelf). Maar dat is niet een al te groot probleem, en kan worden 
opgelost met impliciete regels voor de streetrelatie van hierboven.

Bijgevolg is mijn dogma dat je me nooit een fietspad zal apart zien 
aanmaken als het op het trottoir is ingebed, of als het vlak naast de 
weg ligt. En als het er zo uitziet als in 
http://www.lennisheuvel.nl/pics/fietspad.jpg zal ik het in zeer 
zeldzame gevallen nog wel eens tekenen, maar dan vooral omdat er een of 
andere vreemde bocht inzit.

 Dus als je zelf geen fietspaden apart wilt mappen: prima, mijn motto
 is altijd je moet/mag alleen doen waar je plezier in hebt. Maar
 veroordeel niet de mensen die dat wel doen. En verwijder al helemaal
 niet die fietspaden, dan krijg je een edit war.

Tuurlijk, maar als mensen bepaalde fietspaden tekenen die ik nooit zou 
doen, wil ik wel altijd hun argumenten eens horen...

Ben


(*) en dat heb ik dus één keer gedaan, en toen zag ik ernaar, heb alles 
van fietspaden terug verwijderd en dan ben ik er meteen voor altijd mee 
gestopt. Productiviteit gaan namelijk fel achteruit als elk kruispunt 
een puzzel wordt :-)


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

Re: [OSM-talk-nl] Fietspaden kots

[Ben Laenen]

On Saturday 27 December 2008, Lambertus wrote:
 Dat is jouw mening en lijkt me erg gebaseerd op jou idee hoe een
 kaart eruit zou moeten zien en niet welke informatie we willen
 verzamelen. Uiteindelijk gaat OSM over het verzamelen van informatie
 en niet het maken van een (lelijke) slippy map. Persoonlijk map ik
 ook geen trottoirs, lantaarnpalen of putdeksels maar als iemand dat
 wel wil doen, prima. En als jij een kaart wilt maken zonder voetpaden
 langs de wegen dan kan dat evenals diegene die dat juist wél wil,
 gewoon een kwestie van filteren.

Mijn mening is dat als je trottoirs met aparte objecten mapt, je dat 
moet doen met polygonen en niet met lijnen. Aangezien trottoirs nu 
eenmaal altijd tegen de rijweg aanliggen kan je niet meer informatie 
geven dan hier is een trottoir en eventueel de breedte op elk punt. 
En dat kan je dan evengoed op de way van de straat zelf toevoegen dan, 
tenzij je erop staat je leven moeilijk te maken :-)

Als je trottoirs met aparte objecten wil mappen ga ik ervan uit dat je 
de volledige vorm van het trottoir wil ingeven, en dat kan enkel met 
polygonen. Maar in dat geval moet je ook wel de oorspronkelijke weg als 
polygoon hebben om niet te vreemd te doen...


  Al begrijp ik ook dat het ideale tweedimensionaal invoeren van
  wegen (dus straten als oppervlakken in plaats van lijnen) ook niet
  direct voor morgen is...

 Voor jou misschien ideaal. Voor mensen die een zo hoog mogelijke
 detail willen wellicht juist niet. Hoe wil je overigens die vlakken
 gaan mappen? Een lijntje in het midden en dan allemaal breedtes
 opgeven, of het tekenen van allemaal rechthoeken waarbinnen tags
 duidelijk moeten maken wat er allemaal is (middenberm, wegen,
 buitenberm, fietspaden, voetpaden)?

Zoals de officiële kaarten bij bouwplannen en dergelijke: polygonen voor 
de straten, polygonen voor de fietspaden, de trottoirs, de bermen, 
parkeerplaatsen... Stel bijvoorbeeld voor dat je dit in OSM ziet: 
http://fietsersbondheezeleende.dse.nl/heeze_2_fietspaden_deelD.jpg .
Ik begrijp niet wat je dan bedoelt met Voor mensen die een zo hoog 
mogelijke detail willen wellicht juist niet. Wat mij betreft is het 
invoeren van wegen en alles wat op die wegen ligt, hangt of staat met 
polygonen zowat het gedetailleerdste dat mogelijk is (of je moet al 
volledige driedimensionale modellen maken van bushokjes, gebouwen, 
verkeerslichten, etc.), en komen de mogelijkheden van lijnen niet in de 
buurt, tenzij je het begrip lijn met breedte invoert, maar dat zijn 
dan ook vermomde polygonen.

Maar goed, dat is enkel een denkoefening nu en niet echt aan de orde 
want ik zie het niet echt onmiddellijk populair worden dat alle OSM'ers 
met landmetermateriaal de straten gaan afmeten, en onze gps'en zullen 
ook niet direct op tien centimeter na nauwkeurig gaan worden.

  Een ander probleem met alle aparte fietspaden is dat je access
  regels zo goed als zeker niet meer kloppen (lees: geen bicycle=no,
  op de weg zelf). Maar dat is niet een al te groot probleem, en kan
  worden opgelost met impliciete regels voor de streetrelatie van
  hierboven.

 Dat is dus wat ik ook doe, gewoon bycycle=no op een weg waar een
 fietspad naast is getekend.

Dan ben jij een grote uitzondering :-)

Hoe dan ook, 't is onvolledig (tenminste voor België), want dan zijn er 
ook regels voor bromfietsers (klasse B verplicht of verboden op 
fietspad, en soms mag die kiezen), en de regel dat je bij een 
richtingswijziging toch de rijbaan mag volgen als er een verplicht 
fietspad is.

Dat werkt enkel met impliciete regels, maar afijn, dat is een andere 
discussie...

Ben

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

[OSM-talk-nl] Duitse grens

[Ben Laenen]

Even waarschuwen dat de Duitse grens volledig is aangepast ergens de 
voorbije dagen of weken, en dat het er bijgevolg een klein boeltje is 
geworden. Er zal iemand bijgevolg heel de grens moeten afgaan om het 
terug in orde te brengen (relaties van gemeenten, provincies en landen, 
enzomeer)...

Ben

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

Re: [OSM-talk-nl] fietsroute

[Ben Laenen]

On Thursday 15 January 2009, YRS wrote:
 Hallo,

 Ik vond een fietspad met een bordje in een gebied dat ik aan het
 loggen ben. Het blijkt een fietsroute te zijn die vrij lang is. Nu
 lees ik op de wiki
 http://wiki.openstreetmap.org/wiki/Relations/Routes#JOSM dat ik
 alleen een route mag invoeren die compleet is :-(

 Is dat echt zo? Mag ik niet een paar kilometer route invoeren die ik
 tegenkom?

 Hoor graag van julie,

Ik weet niet echt waar je dat hebt gelezen, maar je mag gerust delen van 
routes ingeven hoor, iemand anders of jezelf kan het later wel 
aanvullen.

Een geluk ook dat je de langeafstandsfietsroutes bijvoorbeeld niet in 
één trek moet ingeven :-)

Ga wel eerst na of de route al is aangemaakt voor een ander stuk als het 
zo'n lange route is, zodat je jouw stuk daar kan aan toevoegen als dat 
zo is.

Ben

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

Re: [OSM-talk-nl] Fietsroutes Incrorrect getagged

[Ben Laenen]

On Tuesday 03 February 2009, René Affourtit wrote:
 Hoi,

 Gert wrote:
  wat is de meerwaarde van het opnemen van de nodes in de relatie

 Dat is een afspraak die bij mijn weten al een tijd staat. Het idee
 was dat je zo makkelijk kan zien of een route compleet is (?). Het
 heeft alleen altijd een beetje ondergesneeuwd gestaan op de wiki,
 vandaar dat het nu expliciet genoemd wordt. En natuurlijk zou je ze
 ook automatisch op kunnen zoeken.

Vraag is natuurlijk of het niet even makkelijk te zien is als de 
uiteindes van die routes een node hebben met een rcn_ref... En horen de 
knooppunten ook misschien niet eerder thuis in de overkoepelende 
netwerk-relatie?


 Het verhaal met state=connection in (B) voor een route tussen
 netwerken valt me nu pas op en is (in mijn ogen) overdone. Connection
 zie ik als verbinding tussen bijvoorbeeld een stadscentrum en een
 node. routes tussen netwerken verschillen niet van routes binnen een
 netwerk.

state=connection is voor volgende gevallen in de knooppuntnetwerken:
* verbinding POI of dorps-/stadscentrum met netwerk
* in een uitzonderlijk geval (ik ken slechts één geval hier in België) 
wordt ook eens een verbinding gemaakt tussen twee routes van het 
netwerk zelf. Dat stuk is dan geen echte route van het netwerk, en 
heeft geen knooppuntbordjes, maar is als tekst langs de route aangeduid 
dat je die doorsteek kan maken.

connection if the route connects two cycle node networks zoals op de 
pagina staat hoort inderdaad niet voor state=connection.

Bij lusvormige routes is state=connection soms ook gebruikt om de 
verbinding tussen twee dergelijke routes te mappen.

Ben

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

Re: [OSM-talk-nl] Licentie veranderingen

[Ben Laenen]

On Wednesday 11 February 2009, Stefan de Konink wrote:
 Ga je akkoord met licentie wijziging (ja/nee), wanneer je niet
 akkoord gaat bestaat de mogelijkheid dat we al je data wissen.

Gaat dat werkelijk de vraagstelling zijn? Waarom kan het niet iets 
neutraler als:

Ben je akkoord met de licentiewijziging? Ja/Nee/Geen mening

Waarbij dan duidelijk wordt gesteld dat die vraag niet meteen je data 
onder een andere licentie zet als je ja antwoord. Dit is dus enkel om 
te zien hoe er gereageerd wordt door de community.

Pas later als het resultaat bekend is en blijkt dat de *overgrote* 
meerderheid de wijziging ziet zitten (en met overgroot bedoel ik dus 80 
of 90%, of je riskeert erg veel data te verliezen), dán pas moet er 
gesproken worden over het effectief wijzigen van de licentie van ieders 
ingegeven data, waarbij dan een nee zou betekenen dat het misschien 
naar een database gaat onder CC-BY-SA die (tijdelijk) een onderdak 
biedt aan die data, waarbij OSM zelf de data die niet onder de nieuwe 
licentie staat verwijdert in de hoofddatabase.

Afijn, dat is toch mijn gedacht van een iets betere en vriendelijkere 
procedure...

Ben

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

Re: [OSM-talk-nl] Licentie veranderingen

[Ben Laenen]

On Wednesday 11 February 2009, Stefan de Konink wrote:
 Ben Laenen wrote:
  On Wednesday 11 February 2009, Stefan de Konink wrote:
  Ga je akkoord met licentie wijziging (ja/nee), wanneer je niet
  akkoord gaat bestaat de mogelijkheid dat we al je data wissen.
 
  Gaat dat werkelijk de vraagstelling zijn? Waarom kan het niet iets
  neutraler als:
 
  Ben je akkoord met de licentiewijziging? Ja/Nee/Geen mening

 Exacte quote die ik binnen kreeg:

 * if OSMF members agree then license is going to show up on the web
 page with something click here to accept/click here not to accept
 and then if you click no you get a message telling you are you
 sure... your data might have to be deleted...

En wat zou er dan gebeuren met data die ooit eens gewijzigd is door 
iemand die zijn toestemming niet geeft om een of andere reden, en 
waarna anderen de wegen hebben aangepast? Sorry, je data is niet 
afgeleid van data onder 'nieuwe licentie X', dus ook al ging je zelf 
akkoord, die wegen worden bij deze gedeletet

Als je dan pech hebt dat ooit een hele stad is aangemaakt (bv. getracet 
met satellietfoto's) door zo iemand en daarna volledig is verbeterd 
door anderen...

Ben

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

Re: [OSM-talk-nl] Licentie veranderingen

[Ben Laenen]

On Friday 13 February 2009, Henk Hoff wrote:
 Er zal hoe dan ook een moment komen dat we aan iedereen moeten vragen
 of zij akkoord zijn met deze nieuwe licentie. Dat wordt een ja/nee
 vraag. Er zal vanaf dat moment ook een freeze moeten komen op de
 database; danwel je mag alleen maar editen wanneer je akkoord bent
 met de nieuwe licentie. Dat is alleen al uit praktische overwegingen
 noodzakelijk. Het moment van de freeze is namelijk het moment waarom
 alle data nog onder de huidige licentie valt.
 Let wel: deze vraag zal niet direct worden gesteld nadat de licentie
 is vrijgegeven. Er is zal nog een periode zijn, zoals net gemeld, dat
 de licentie besproken kan worden.

Maar hoe denk je ooit om een ja te krijgen van alle mensen die ooit iets 
hebben geëdit in OSM? Volgens mij ga je nog niet aan de helft geraken 
van alle contirbutors die op de vraag zullen antwoorden (laat staan om 
dat in één week voor elkaar te krijgen terwijl de database in freeze 
is - want langer dan een week ga je OSM toch niet in freeze mogen 
houden), aangezien velen in de loop der tijd hun interesse kwijt zijn 
geraakt.

En wat ga je dan doen met die mensen die indertijd veel hebben gedaan en 
waar zoveel andere mensen later op verdergebouwd hebben. Ik durf er 
niet aan denken dat mijn uren werk wordt gedeletet omdat ooit in de 
geschiedenis van al die wegen iemand is geweest die zijn toestemming 
niet heeft gegeven.

Dus: wat ga je daaraan doen? Negeren dat er mensen geen toestemming 
gegeven hebben (niet bepaald een voorbeeld voor een project dat zich 
juist bezighoudt met de licentie)? Als daar nu nog geen oplossing voor 
is gevonden kan je je maar beter niet meer bezighouden met een 
licentiewijziging.

 Laat het ook helder zijn dat ons (als Foundation) er alles aan
 gelegen is zoveel mogelijk members (liefst iedereen) te overtuigen
 dat de nieuwe licentie beter is dan de huidige. Er zal in het proces
 dus ook een go-nogo moment komen. Wanneer maar 50% van de data
 overgezet kan worden, kun je afvragen of het dan nog wel slim is om
 door te zetten.

En ik wil ook wel weten hoe je die data waarvoor je toestemming hebt 
gaat tellen. Als een import zoals die van TIGER meetelt als een ja 
heb je ongetwijfeld al zeker 50% van alle data in OSM. Maar daar steekt 
dan wel geen werk in van eender welke vrijwilliger.

En wat is dan wel een aanvaardbaar percentage? 70%? 90%? 95%? 99%? En 
als die 1% in dat laatste geval alle data van een volledig land omvat?

Ben

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

Re: [OSM-talk-nl] rendering van natural=heath

[Ben Laenen]

On Monday 23 February 2009, paul van den berg wrote:
 Hallo lijst,

 ik zou wel wat gebieden willen mappen als heideveld (natural=heath),
 maar deze worden nu standaard gerendered in praktisch dezelfde kleur
 als natural=wood (groen), zodat je op de kaart geen verschil kunt
 zien. Op Nederlandse kaarten zijn ze meestal paars.

En zowel op t...@h en Mapnik wordt het toch geel weergegeven? 
http://www.openstreetmap.org/?lat=51.398lon=4.4297zoom=14layers=B000FTF

Ben

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

[OSM-talk-nl] Updates wandelroutelayer tile.openstreetmap.nl?

[Ben Laenen]

Het lijkt erop alsof zoom levels 12, 13,... van de wandelroutelayer niet 
meer zijn geüpdatet de voorbije maand. Kan iemand er eens naar kijken?

Ben

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

[OSM-talk-nl] Wandelroutes op tile.openstreetmap.nl

[Ben Laenen]

Een vraagje aan de persoon die instaat voor het renderen van de 
wandelroutes op tile.openstreetmap.nl:

Is het mogelijk om net zoals bij de fietsroutes verschillende layers te 
maken voor de netwerken lwn/rwn/nwn? Of indien dat niet mogelijk is 
toch minstens verschillende kleuren voor de drie netwerken te voorzien? 
De drie netwerken staan volledig los van elkaar, maar op dit moment is 
alles blauw en het is nagenoeg onmogelijk op sommige plaatsen om nog de 
juiste route te kunnen volgen...

Ben

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

Re: [OSM-talk-nl] Wandelroutes op tile.openstreetmap.nl

[Ben Laenen]

On Monday 13 April 2009, Lennard wrote:
 Bedoel je www.openwandelkaart.nl ?

Inderdaad

 Ja, dat is zeker wel mogelijk. Ik ben op het moment bezig met
 www.openfietskaart.nl, en daarna komen de wandelroutes aan de beurt.

 Welke kleuren passen het beste bij welk netwerk? Dezelfde indeling
 als bij de fietsroutes (n=rood/r=blauw/l=groen), of wellicht iets
 anders? Is er een overwegende kleurstelling op de actuele
 route-aanduidingen?

Tja, dat zal ook wel wat van de Nederlandse routes afhangen. In België 
zijn de nwn routes allemaal wit-rood of geel-rood. De rwn (de 
knooppuntennetwerken) is hier donkerrood, maar in Nederland zijn de 
kleuren groen en geel. En lwn is zoals bij fietsroutes een allegaartje 
aan kleuren en alle kleuren komen voor.

't Is dan ook best om een colour tag te lezen (je kan je voorlopig wel 
beperken tot de basiskleuren als green, yellow, blue enzovoort en 
als je de kleur niet herkent de standaard weergeven)

Voorbeelden van hoe ik het zelf render:

http://wiki.openstreetmap.org/images/7/75/Belgium-walkingnetwork-scheldeland.png
dunste lijnen zijn lwn, donkerrode zijn rwn en de wit-rode en geel-rode 
zijn nwn

http://wiki.openstreetmap.org/images/a/ad/Belgium-walkingroutes-boechout-vremde.png
(adblocker misschien afzetten want er zit /ad/ in die link)
dit toont dat het een stuk leesbaarder is als de lwn routes in de juiste 
kleur worden gerenderd dan alles in dezelfde kleur.
Let ook op bijvoorbeeld de stippellijntjes voor de verkorte routes (die 
hebben de tag state=alternate in hun relatie)

Ben

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

Re: [OSM-talk-nl] Wandelroutes op tile.openstreetmap.nl

[Ben Laenen]

On Monday 13 April 2009, Cartinus wrote:
 Hier zie je meteen waarom ik de splitsing in nwn/rwn/lwn niet prettig
 vind voor wandelroutes. Ik zou (voor tenminste een deel van de
 routes) bij de network tag liever invullen waartoe de route echt
 behoord.

 Dus:
 * network=law voor landelijke routes (rood-witte markering)
 * network=streekpad voor streekpaden (rood-gele markering)
 * network=ns voor NS wandelroutes (rood-witte markering met NS logo)
 * network=regional voor de regionale wandelroutenetwerken
   (groene achtergrond met gele tekst)
 * network=local + colour=* voor de meeste lokale wandelingetjes

Bah, de slitsing is nu gemaakt en al lang in gebruik en we zullen er 
maar mee leven zeker. En in Nederland zijn bij mijn weten de 
LAW-routes, streekpaden en de NS-routes samen ook nog een geheel, die 
gerust bij elkaar in één netwerk kunnen. In België maken we voorlopig 
het onderscheid tussen GR-routes (= LAW van Nederland) en de 
streek-GR's door een colour=white-red of een colour=yellow-red.

Maar door gebruik te maken van algemene tags als nwn/rwn/lwn, tezamen 
met eventueel de colour= zorg je ervoor dat internationale renderers 
niet te veel speciale regels nodig hebben. Moest je bijvoorbeeld enkel 
de paden renderen zoals met de netwerken hierboven, heb je al meteen 
een probleem met de grensoverschrijdende GR-routes en streek-GR's van 
België in Nederland die niet zouden gerenderd worden. En die routes 
gaan soms tientallen kilometers Nederland in, en maken dan ook 
verbindingen met de LAW-routes. Tenzij je natuurlijk ook nog eens zou 
de netwerk-tags van België gaat toevoegen, en dan zit je waarschijnlijk 
ook nog met grensoverschrijdende routes van Duitsland erbij.

Nee, algemene tags als nwn/... zijn gewoon de basistags, verder 
specifiëren kan met andere bijkomende tags.

Ben

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

Re: [OSM-talk-nl] Wandelroutes op tile.openstreetmap.nl

[Ben Laenen]

On Monday 13 April 2009, Cartinus wrote:
 On Monday 13 April 2009 18:16:09 Ben Laenen wrote:
  Nee, algemene tags als nwn/... zijn gewoon de basistags, verder
  specifiëren kan met andere bijkomende tags.

 Op dit moment in een land of drie geloof ik. Nederland en z'n twee
 buurlanden

En ook Ierland en Oostenrijk maken gebruik van nwn/rwn/lwn


 De Engelsen gebruiken uk_ldp voor de langeafstandswandelroutes.

En als je even op 
http://wiki.openstreetmap.org/wiki/WikiProject_United_Kingdom_Long_Distance_Paths
 
zoekt kan je ook verschillende lwn's vinden.


 Hoewel de NS wandelroutes doorgaans delen van de LAW's gebruiken,
 zitten de stukken van en naar het station meestal niet ook in de LAW
 route, daar één netwerk van maken, maakt de NS routes welhaast
 onzichtbaar. Bovendien hebben ze beide duidelijk een andere scope.
 Relatief korte dagwandelingen vs. langeafstandsroutes

Bij mijn weten zijn de meeste wandelaars op de gewone 
langeafstandsroutes ook maar gewone dagjeswandelaars (in onze 
drukbevolkte gebieden is dat goed te doen). Het aantal wandelaars dat 
effectief meerdaagse tochten houdt om de routes voor een heel stuk in 
één trek te volgen is vrij beperkt hier in verhouding tot alle 
wandelaars op die routes.


 On Monday 13 April 2009 18:16:13 Lennard wrote:
  Is een aanvullende tag op de relatie niet beter geschikt voor deze
  verdere onderverdeling, waarbij de network=* dan vrij blijft voor
  de 'generale' indeling in nationaal/regionaal/lokaal.

 Dat is wat mij betreft ook goed. Dan kan ik de network tag gewoon
 weglaten bij bijna alles wat geen LAW of knooppuntennetwerk is. Dat
 zijn IMHO namelijk de enige twee die echt goed in die indeling
 passen.

Je moet network niet echt als netwerk zien. Het gaat gewoon om een 
basistag te geven die een minieme hint geeft aan renderers. Iets 
als deze route is helemaal anders dan deze route, dus render ze 
alsjeblieft anders). En network=lwn is puur om te zeggen dat het een 
lokale route is, en heeft eigenlijk niets meer met netwerken van doen. 
Maar met analogie aan fietsroutes (waar lcn eigenlijk evenveel netwerk 
is als lwn), is het beter om die indeling te behouden.



 On Monday 13 April 2009 18:16:13 Lennard wrote:
  Is er ooit nagedacht over de indeling n/r/l, of is het gewoon
  analoog aan de fietsnetwerken zo gemaakt?

 Daar is zelfs bij de fietskaarten al niet echt goed over nagedacht.
 Het is zoals zoveel dingen in OSM gegroeid. Er was een systeem dat
 in Engeland voor fietskaarten gebruikt werd, voordat er relaties
 bestonden in OSM. In de tag ncn_ref was het belangrijk kort en bondig
 te zijn, bovendien weten alle Britse fietsers wat de afkorting NCN
 betekent. Zodra er met relaties gewerkt ging worden, was het beter
 geweest om die afkorting te dumpen en had network=national of
 network=sustrans een stuk duidelijker geweest.

 Omdat die Engelse rendering in het begin de enige was, is men in
 andere landen dezelfde indeling gaan gebruiken, of die er in
 werkelijkheid nu was in dat land of niet.

 De tags network=lcn is in veel gevallen ook al niet echt waar. De
 meeste locale rondjes vormen (in Nederland in ieder geval) helemaal
 geen netwerk.

Geen idee van Nederland, maar in België heeft elke provincie zijn 
netwerk van lokale fietsroutes. Netwerk, omdat de routes met elkaar in 
verbinding staan en het toelaten om van route 1 naar route 2 te 
springen. En in elke provincie zijn ze dan meestal gelijkaardig 
bewegwijzerd.

Wat lokale wandelroutes betreft is het ongeveer hetzelfde, maar er is 
meer variatie per provincie, aangezien het hier eerder de gemeenten 
zelf zijn die instaan voor de routes. Desalniettemin is de 
bewegwijzering nog redelijk uniform te noemen per provincie.


 Ook voor het OV hebben we het in het verleden over die driesplitsing
 gehad. Maar bij de busroutes die ik deze weken in het zuid-westen van
 Utrecht aan het invoeren ben, laat ik de network tag ook weg. Het
 onderscheid tussen stads- en streekvervoer is rond Utrecht nogal
 vaag. Je hebt duidelijke stadsbussen, duidelijke streekbussen, maar
 ook buslijnen die er tussenin hangen. Bovendien gebruiken de Duitsers
 (die met de öpnv-karte op dit moment duidelijk het voortouw nemen op
 dit gebied) de network tag om de naam van het Tarifverbund waarbinnen
 de lijn valt aan te geven.

Openbaar vervoer is een heel ander verhaal. Daar moeten we niet naar 
kijken wat betreft wandelroutes. Kijken naar fietsroutes is veel 
logischer hier.


In elk geval, als we gaan voor een nieuwe reeks tags dan is het best 
daar nu aan te beginnen. Maar wat stel je dan exact voor? Me dunkt dat 
een indeling als international/national/regional/local sowieso nodig 
is als hint aan de renderers. Het lijkt me eenvoudigst om daar de 
bestaande network tag voor te gebruiken, maar blijkbaar wordt te veel 
gekeken naar dat netwerk-gegeven.


Ben

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

Re: [OSM-talk-nl] Wandelroutes op tile.openstreetmap.nl

[Ben Laenen]

On Monday 13 April 2009, Lennard wrote:
 Lennard wrote:
  Als er een goed, werkend schema komt, waar zowel de Nederlandse als
  Belgische fiets- en wandelroutes inpassen, waarom zouden we dan
  niet overgaan? We hebben een openfietskaart.nl en
  openwandelkaart.nl, en we kunnen dus prima wijzigingen verwerken.
  Het grote nadeel zou zijn dat je dan wellicht buiten de rendering
  van opencyclemap.org gaat vallen, als die niet wil volgen.

 En wat ik me net bedenk: dan moet ook osm2pgsql aangepast worden,
 want op dit moment verwerkt deze alleen [nrl][cw]n routes.

Ja, dankzij het feit dat iemand mijn snel-snel ineengeklutste code om 
die fietsroutes te behandelen heeft doorgespeeld naar de code van de 
internationale osm2pgsql :-p .  En vooruitziende mens dat ik was had ik 
meteen ook de wandelroutes erbij gezet... En ik dacht dat er ook nog 
wel wat meer rommel zo in osm2pgsql is terecht gekomen :-D

Hoe dan ook, 't is niet erg moeilijk om aan te passen indien nodig (maar 
hoe wenselijk is het?). Ik veronderstel dat je het sowieso wel al moet 
aanpassen om bijvoorbeeld een colour tag te lezen. En het lezen van 
een colour tag is de grootste truuk om de routes leesbaar te maken op 
de kaart.

Ben

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

Re: [OSM-talk-nl] NL tileserver updates

[Ben Laenen]

On Monday 27 April 2009, l...@xs4all.nl wrote:
  Als je nu een fatsoenlijke distributie pakt waarbij je niet alles
  zelf hoeft te compileren, we leven tenslotte niet meer in 1990...
  :p

 Gelukkig compileren we zelf, zodat we makkelijker en sneller bij
 kunnen blijven, zonder van derden en hun RPM'etjes afhankelijk te
 zijn. :p

Je bent toch niet alles aan het compileren à la Linux From Scratch hoop 
ik? Dat je de programma's die nodig zijn om te renderen compileert daar 
kan ik inkomen, maar al de rest compileren is voor niets nodig, en zal 
het onderhoud over langere tijd compleet ondoenbaar maken (tenzij je 
iemand hebt die daar full time mee kan bezig zijn misschien)...

Ben

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

Re: [OSM-talk-nl] OSM voor de brandweer?

[Ben Laenen]

On Friday 15 May 2009, Lambertus wrote:
 Het moet mogelijk zijn om voor Nederland (volautomatisch dan wel op
 request) een OSM Garmin kaart te produceren die enkele minuten of
 uren achterloopt op de centrale database. Daarmee zouden we dit soort
 situaties ondervangen maar dan moet je de Garmin natuurlijk wel aan
 een pc hangen voor een update.

 Met een volledig opensource systeem op een PDA o.i.d. met GPRS
 aansluiting is het zelfs mogelijk om de apparaten vrijwel realtime up
 to date te houden.

Ik zou toch opteren voor allereerst een vorm van quality assurance te 
introduceren voor je zo ver gaat als de kaarten voor hulpdiensten te 
gebruiken en ze zelfs automatisch te laten updaten.

En dan nog andere problemen: ik denk niet dat je wil dat de brandweer 
een paar minuten gaat omrijden bij een oproep omdat de OSM snapshot 
juist gemaakt is terwijl iemand een kruispunt aan het bewerken was en 
nog niet alle verbindingen had gemaakt... En dan heb ik het nog niet 
over kwaadwillige bedoelingen.

En wie is dan aansprakelijk als blijkt dat een fout in de kaarten van 
OSM ervoor gezorgd hebben dat iets erger werd? Hoe zit dat met 
commerciële kaarten?

Ben

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

Re: [OSM-talk-nl] maximumsnelheden.nl

[Ben Laenen]

On Saturday 16 May 2009, Freek wrote:
 Zie hier:
 http://wiki.openstreetmap.org/wiki/Common_licence_interpretations#I_c
reated_a_layer_on_top_of_an_OSM_map._What_do_I_have_to_put_under_your_
license.3F

 Het gaat er blijkbaar om of je een /derivative/ of /collective/ work
 maakt. Ik heb geen idee wat het is. Ik hoop dat je de data gewoon mag
 gebruiken, maar ik vind zelf dat het op de huidige website niet
 helemaal duidelijk is dat de landuse informatie van OSM komt.

Wel, gezien het hier gaat om twee datasets die compleet onafhankelijk 
zijn van elkaar wordt het hier toch eerder collective work.

Om het helemaal zeker te zijn kan je misschien wel de OSM-achtergrond op 
een aparte layer zetten met de straten zelf als transparante overlay, 
ipv samengesmolten op één rendering, dan is er geen discussie meer 
mogelijk, en het resultaat ziet er exact hetzelfde uit.

Maar er zo direct vanuit gaan dat het hele NWB nu ook meteen CC-BY-SA is 
is wel een beetje kort door de bocht gaan...

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

Re: [OSM-talk-nl] maximumsnelheden.nl

[Ben Laenen]

On Saturday 16 May 2009, Lambertus wrote:
 Nu vind ik de reaktie van Stefan (claimen dat het NWB dus nu door OSM
 gebruikt mag worden) wel wat agressief, ik wil zover niet gaan
 aangezien ik denk dat het hier om een misverstand gaat. De meeste
 mensen zullen het beschikbaar stellen van de data ook belangrijker
 vinden dan de licentie. Ik vind ook niet dat we dus nu de NWB data
 maar mogen overnemen. Mochten we dat doen dan bestaat de kans dat we
 in de rechtzaal belanden waar het project niks mee opschiet.

De reactie van te claimen dat het NWB nu door OSM gebruikt mag worden is 
trouwens ook helemaal verkeerd, want het is eenvoudigweg niet zo.

Als een zeker persoon X de kaarten van google maps neemt en dan die 
kaarten aanpast en inkleurt met behulp van OSM data, is de reactie 
eigenlijk hetzelfde als zeggen dat google maps dan ook maar ineens 
CC-BY-SA is.

Als in dit geval RWS niet helemaal in orde is met CC-BY-SA (al laat ik 
die discussie voor anderen) dan heeft dat geen effect op de licentie 
van de data van NWB. Zolang RWS niet zegt dat de data allemaal CC-BY-SA 
is mag je daar niet vanuitgaan, ook al zou het CC-BY-SA moeten zijn.

Ben

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

Re: [OSM-talk-nl] maximumsnelheden.nl

[Ben Laenen]

On Saturday 16 May 2009, Stefan de Konink wrote:
 Ben Laenen wrote:
  Als in dit geval RWS niet helemaal in orde is met CC-BY-SA (al laat
  ik die discussie voor anderen) dan heeft dat geen effect op de
  licentie van de data van NWB.

 Kun je dan spreken van een 'illegaal' product?

Het betekent dat je met RWS moet bespreken hoe het zit met de licentie 
en dat uitklaren.

Of je daar nu direct stempels als illegaal moet opplakken, moet jij 
weten. Maar volgens mij kan je meer bereiken zonder meteen zo'n termen 
te gebruiken. Kwestie dat je hier ook niet echt kan spreken van kwaad 
opzet, moest het werkelijk niet mogen volgens CC-BY-SA.


 Het is duidelijk dat RWS deze data distribueert; dan wel opdracht
 gegeven heeft om deze site te maken. RWS is eigenaar van het NWB, dus
 als RWS het NWB samenvoegt met CC-BY-SA data... wat is het
 eindproduct dan?

Zolang de persoon die de data publiceert het niet de stempel CC-BY-SA 
geeft, is het dat ook niet, of dat nu zo zou moeten of niet. En het 
enige dat je kan doen is van die persoon verkrijgen dat de licentie 
juist wordt nageleefd, hetzij door het de stempel CC-BY-SA te geven, 
hetzij door het zo aan te passen dat het aan de licentie voldoet.

Maar je mag dus niks doen met de gepubliceerde kaarten van RWS omdat de 
licentie daarvan niet CC-BY-SA is gemaakt (of het nu zo mag of niet).

Ben

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

Re: [OSM-talk-nl] http://maximumsnelheid.openstreetmap.nl/

[Ben Laenen]

On Monday 18 May 2009, Maarten Deen wrote:
 Ik ben er voorstander van om alle wegen expliciet met een
 maximumsnelheid te taggen.

Het probleem met taggen van impliciete snelheden ligt hem gewoon in het 
feit dat impliciete snelheden wel eens kunnen veranderen in de loop van 
de jaren. Stel dat men over een paar jaar zegt dat in bebouwde kom ipv 
50 nog maar 40 mag ('k zeg maar iets), dan heb je een probleem omdat je 
niet meer weet of die maxspeed=50 getagd was aan de hand van een 
verkeersbord dat daar staat of omdat het gewoon de snelheid van een 
bebouwde kom was. Dus kan je alle straten met maxspeed=50 opnieuw 
afrijden om te zien of er nu een bord stond of niet (of ten minste 
iedereen ergens in zijn logs op zoek laten gaan naar zijn nota's).

Ten tweede: ga er nooit vanuit dat mappers al hun verkeersregels kennen. 
Ik ben er zeker van dat als je hier in België willekeurig mensen vraagt 
hoe snel je exact mag op een woonerf of erf je uiteenlopende antwoorden 
gaat krijgen. Niet iedereen heeft zijn verkeersregels fris in het 
achterhoofd zitten.

Ten derde: er zijn honderden impliciete tags, die in elk land 
verschillen. Waar trunk in Nederland bicycle=no impliceert is dat niet 
zo in het Verenigd Koninkrijk. En vermoedelijk zijn er wel landen waar 
highway=motorway niet impliceert dat voetgangers verboden zijn. 
Access=destination heeft geen effect op ruiters en fietsers in land X, 
waar het wel moet worden toegepast door hen in land Y. hgv is een tag 
die niets betekent in België en eigenlijk als synoniem voor goods 
geldt, omdat bij verkeersborden hier enkel onderscheid wordt gemaakt 
bij voertuigen voor het vervoer van zaken aan de hand van een expliciet 
gewicht bij dat verkeersbord, dus betekent goods=no in Duitsland dat 
enkel lichte vrachtwagens niet mogen, in België mag dan geen enkele 
vrachtwagen. In België mag ook een vrachtwagen van meer dan 7.5 ton 
niet inhalen op een weg met minimum vier rijstroken bij regen, sneeuw 
of hagel, begin de wegen daar maar eens mee te taggen allemaal. En dan 
zijn er nog aparte impliciete snelheden naargelang de massa en het type 
van voertuig, die zeker niet gekend zijn door 99% van de mensen, en ook 
anders zijn in elk land (en die makkelijker veranderen dan 
snelheidsregels voor gewone automobilisten -- twee jaar terug nog voor 
België bijvoorbeeld).

En zo kunnen we door blijven gaan. Dus zitten we met een enorm aantal 
landspecifieke kenmerken en er moet bijgevolg al sowieso een 
tussenstadium zijn tussen het plukken van data uit de API en het 
gebruik van de data in bvb je gps of een routeplanner, namelijk 
het vertalen, en het is dat vertalen dat zal instaan voor impliciete 
tags toe te kennen aan de juiste wegen, zodat je uiteindelijk als 
gebruiker de juiste regel ziet.

Het taggen van de impliciete tags is nu wel een leuk lapmiddeltje om het 
huidige gebrek aan zo'n vertaler goed te maken, maar in de toekomst 
krijg je vroeg of laat wel problemen met zo'n impliciete regels omdat 
verkeersregels nu eenmaal veranderen in de tijd, en dan kan je niet 
meer zeggen of je tag expliciet of impliciet op de weg te vinden was.

Ben

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

Re: [OSM-talk-nl] Openfietskaart.nl Beta 2

[Ben Laenen]

On Tuesday 19 May 2009, Theun wrote:
 Wel weer jammer dat vaak op een kruispunt in het midden van een
 dorpje waar een knooppunt is gekozen vaak ook een place-tag staat,
 waardoor de plaatsnaam dwars over de knooppunt-aanduiding staat.

Daar valt voorlopig toch weinig tegen te doen. We kunnen moeilijk die 
nodes gaan zitten verplaatsen omdat het op deze kaart nu toevallig voor 
problemen zorgt.

En zelfs als Mapnik ooit een functie zal hebben om plaatsnamen uit de 
weg te zetten voor andere features, dan gaat het hier nog niet 
vanzelfsprekend zijn om het op te lossen aangezien de knooppunten op 
een andere layer zitten, en wat dan weer werkt voor fietsknooppunten 
kan dan weer niet werken voor wandelknooppunten bijvoorbeeld.

Ben

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

Re: [OSM-talk-nl] http://maximumsnelheid.openstreetmap.nl/

[Ben Laenen]

On Wednesday 20 May 2009, Maarten Deen wrote:
 Martijn van Exel wrote:
  Eens. Je kunt wel redundante informatie blijven toevoegen, maar dan
  wordt het echt onbeheersbaar. Het feit dat een object binnen
  Nederland ligt conformeert, als niet anders aangegeven, aan de
  Nederlandse standaard als vastgelegd in wet- en regelgeving.

 Het voorbeeld van Ben is uit zijn verband getrokken. Die regels
 gelden voor alle wegen. Maximum snelheden zijn erg verschillend.

 Stel dan eerst maar eens de regels op welke wegen wel en welke wegen
 niet en in welke omstandigheden met een maxspeed te taggen zijn. Ik
 heb al aangegeven dat dat een uitgebreide set regels wordt die ik als
 mapper niet altijd snel kan toepassen (als ik een gedeelte van een
 kaart download dan weet ik niet of ik wel of niet binnen de bebouwde
 kom zit bijvoorbeeld, nog afgezien van het feit dat niet alle
 bebouwde kommen (goed) zijn gemapt).

't is nochtans zeer eenvoudig: tag enkel wat er te vinden is op de weg, 
want als er iets te vinden is dan betekent het dat het anders is dan de 
default (of soms een herinnering aan die default). Dus als er een 
snelheidsbord staat kan je dat taggen. En als er niets te vinden is, 
moet je het ook niet taggen. Als een automobilist slim genoeg moet zijn 
om te weten welke snelheid hij mag dan gaat een computer dat ook wel 
kunnen.

Het feit dat er nog geen goeie manier is om te zeggen hoe de bebouwde 
kom of snelheidszones juist liggen is een tijdelijk probleem, want het 
zal eens moeten opgelost geraken.


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

Re: [OSM-talk-nl] http://maximumsnelheid.openstreetmap.nl/

[Ben Laenen]

  IMHO is het dan toch veel en veel simpeler om het allemaal te
  taggen. Ook dingen die impliciet lijken.

 Helemaal mijn idee!

Begin dan maar met het taggen van motorcar=yes op elke weg, motorcar=no 
op elk fietspad, oneway=no op elke weg, en wat weet ik nog allemaal. 
Dat is namelijk ook allemaal impliciet.

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

Re: [OSM-talk-nl] http://maximumsnelheid.openstreetmap.nl/

[Ben Laenen]

On Wednesday 20 May 2009, Maarten Deen wrote:
 Ben Laenen wrote:
  Het feit dat er nog geen goeie manier is om te zeggen hoe de
  bebouwde kom of snelheidszones juist liggen is een tijdelijk
  probleem, want het zal eens moeten opgelost geraken.

 Goh, en het wordt steeds gezegd dat de snelheid op de way taggen geen
 oplossing is. Maar wel dat een andere methode die er niet is de
 oplossing is. Ik snap het niet.

Bah, ik heb al lang de oplossing voor het taggen van zone 30's en 
gelijkaardige zones, aangezien het een vanzelfsprekende uitbreiding was 
op wat ik hier probeerde op te lossen: 
http://wiki.openstreetmap.org/wiki/Proposed_features/Access_restrictions

Als we relaties zullen nodig hebben voor ingewikkeldere restricties, dan 
kan je dat bij uitbreiding ook voor eenvoudigere maxspeed=30 
restricties, samen met dan een zone=yes tag. En hokus pokus, het 
beheren van zones in een stad als Antwerpen wordt opeens een stuk 
overzichtelijker, en ik heb het al een paar keer uitgetest: 
http://wiki.openstreetmap.org/wiki/Antwerpen/Zones (waarbij je merkt 
dat zones een naam en soms een nummer hebben -- informatie die 
waardevol is om het te onderhouden later maar die verdwijnt bij tags op 
ways). (*)

En ten slotte is het mij daarom te doen: het makkelijk beheerbaar houden 
van de data. We zijn in de eerste plaats mappers, en we moeten zorgen 
dat die data makkelijk te bewerken blijft naar de toekomst toe wanneer 
situaties onvermijdelijk veranderen: nieuwe verkeersborden die her en 
der geplaatst worden, of nieuwe verkeersregels die een heel land kunnen 
beïnvloeden (in Vlaanderen wordt bv. gesproken over het verlagen van de 
snelheid op wegen buiten de bebouwde kom van 90 naar 70 en dat kan over 
een paar jaar een feit zijn, dus zo exotisch is het echt niet). En dan 
kan je in dat geval alle wegen die getagd waren met maxspeed=90 opnieuw 
afgaan om te zien of ze impliciet waren, of dat er werkelijk een bord 
90 stond (en moet je dat dan ook weer ergens bijhouden om ervoor te 
zorgen dat meerdere mappers niet dezelfde wegen gaan controleren). En 
ik denk dat er in België nog wel genoeg ander werk is, dat het beter is 
geen tijd daaraan te verspillen als het niet nodig is.

Ben



(*) En ik heb nog nooit een goed argument gehoord tegen het gebruik van 
relaties voor dingen als zone 30's en bij uitbreiding bebouwde kommen. 
De enige die worden gebruikt zijn: dat gaan grote relaties worden (so 
what? enig idee hoeveel members bepaalde routes tegenwoordig al niet 
hebben?) en relaties zijn te moeilijk voor beginners (maar relaties 
zijn gewoon één van de drie basisstructuren in OSM, kunnen we er 
eindelijk van uitgaan dat de tijd dat relaties nieuw waren voorbij is 
en dat een mapper tenminste de moeite doet om het principe van relatie 
te begrijpen?), en de laatste is je gaat een way vergeten, maar dat 
valt dan weer op te lossen met nodige tools of probleemcheckers, ook 
net zoals dat geburt voor routes op dit moment.



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

Re: [OSM-talk-nl] Openwandelkaart.nl

[Ben Laenen]

De route daar mist de type=route tag, en daardoor rendert die niet.

'k heb de relatie aangepast.

Ben


On Friday 29 May 2009, ce-test, qualified testing bv - Gert Gremmen 
wrote:
 Kwa kleurstelling kan er nog wat verbetert worden.
 Wie ziet op onderstaande link het wandelpad ???

 http://openwandelkaart.nl/?zoom=16lat=51.96818lon=4.39711layers=B
000FTFTTF




 Gert Gremmen
 -

 Openstreetmap.nl  (alias: cetest)
  Before printing, think about the environment.



 -Oorspronkelijk bericht-
 Van: talk-nl-boun...@openstreetmap.org
 [mailto:talk-nl-boun...@openstreetmap.org] Namens Freek Verzonden:
 Friday, May 29, 2009 9:03 AM
 Aan: OpenStreetMap NL discussion list
 Onderwerp: Re: [OSM-talk-nl] weblog nu op (we)blog.openstreetmap.nl

 On Friday 29 May 2009, Stefan de Konink wrote:
  Om direct weer even in de 'get it done' mentaliteit te komen.
  http://www.openstreetmap.nl/ bevat nu het grootste gedeelte van de
  eerder besproken actiepunten. http://openstreetmap.nl/ een wat
  directere manier van linken. Gelukkig hebben we zaterdag een
  designer in de zaal.

 Ik zie dat openwandelkaart.nl ook geupdate is, mooi! Ik kijk er naar
 uit om die komende zomer weer verder uit te breiden :-)



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

Re: [OSM-talk-nl] Wandelroute taggen

[Ben Laenen]

On Thursday 04 June 2009, Maarten Deen wrote:
 Bij ons in de buurt kom ik wandelroutes tegen met bordjes als in het
 bijgevoegde plaatje.
 Iemand tips hoe ik deze moet taggen?

 Overigens heb ik niets over deze route op de site van de ANWB kunnen
 vinden.

 Maarten


We gebruiken daar netwerk=lwn voor in België. Zie 
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Walking_Routes#Local_walking_routes

lwn is zowat de verzameling van alle kleinere wandellussen.

Ben

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

Re: [OSM-talk-nl] relatie bij punt

[Ben Laenen]

On Monday 08 June 2009, Rejo Zenger wrote:
 Ik ben ook een beginner (en ik zal het ook altijd wel blijven), maar
 tot nu toe kreeg ik de indruk dat in dit soort gevallen het als een
 fietspad was getagged en als extra tag pedestrian=yes toegevoegd
 had.

Het moet tussen haakjes natuurlijk wel foot=yes zijn i.p.v. 
pedestrian=yes.

Ben

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

[OSM-talk-nl] Cycleway/footway [was: relatie bij punt]

[Ben Laenen]

On Tuesday 09 June 2009, Myckel Habets wrote:
 Rene Dohmen rdohmen+osm-talk...@gmail.com schreef:
  - als er pedestrian gekozen is in OSM, maar er ook fietsers rijden
  is dan niet een cycleway beter?

 Mijn ervaring is dat vaak wel aangegeven staat of iets een voetpad of
 fietspad is.

Tot daar volledig akkoord, een cycleway is voor een fietspad, en een 
footway voor een voetpad.

 Is dat niet het geval, dan kijk ik hoe het op dat moment 
 gebruikt wordt (als genoeg mensen van de weg gebruik maken) of hoe
 het wegdek er uit ziet (geheel vast geasfalteerd of toch nog wat los
 asfalt er boven op/ruw vast wegdek). Is er dan nog onduidelijkheid,
 dan tag ik het als cycleway met foot=yes.

En dat vind ik helemaal niet zo. Je gaat zo beginnen interpreteren, en 
de volgende mapper die langskomt zal het anders zien en de mapper 
daarna zal ook weer een ander idee hebben over hoe het gebruikt wordt, 
omdat er misschien net een horde mountainbikers langs komt gereden, of 
omdat er net een stoet ruiters passeert.

Laten we de verkeersregels erbij nemen, en die zeggen dat standaard 
alles mag op een pad wat erop kan als er geen verkeersborden staan. Dus 
hoe ga je bijvoorbeeld ooit een deftige routeplanner maken als je het 
pad waar ruiters mogen tagt met cycleway?

Dus, wat niet is bewegwijzerd als een fietspad (zij het met zo'n 
bord fietspad of zo'n rond blauw bord) kan geen cycleway zijn, en wat 
niet zo'n rond blauw bord met een voetganger heeft kan geen footway 
zijn. Vanaf dan wordt het path als er geen auto's kunnen rijden.

En dan weet een routeplanner bijvoorbeeld ook dat alles daar mag rijden, 
als er dan andere verkeersborden staan kan je die borden dan toevoegen 
als tags (verbodsbord met auto op → motorcar=no, en routeplanner weet 
dan dat hij daar geen bus naartoe moet sturen, of je motorfiets met 
zijspan, maar dat een gewone motorfiets nog gerust daarop mag).

(natuurlijk, vele paden zijn te vinden in natuurgebieden of domeinen, en 
daar gelden soms andere toegangsregels, maar dat is eigenlijk een 
andere discussie, ik heb het hier over gewone publieke wegen)

Nuja, ik weet dat ik wel een beetje inga tegen de drie vaak gebruikte 
manieren van taggen van: er komen nogal veel fietsers dus is het maar 
cycleway (probleem: je weet niet wat daar zoal langskomt de rest van 
de dag/jaar, je oordeel ging enkel over die paar minuten dat je daar 
was), of er kunnen fietsers komen maar niet echt aan te raden als je 
het wegdek ziet, dus footway (probleem: stel dat het net geregend had 
en dat daardoor het wegdek volledig ontoegankelijk was voor fietsers, 
maar dat het bij droog weer gerust een fietsparadijs is; of: waar jij 
niet denkt te kunnen doorgeraken met je fiets is het geen probleem voor 
iemand anders), of het is niet verboden voor fietsers, dus cycleway 
(probleem: wat is het dan als het niet verboden is voor fietsers en 
voor ruiters? bridleway dan automatisch toegankelijk voor fietsers? 
want dat is ook niet meteen zo). En die drie zijn totaal verschillende 
tagging methodes, die al dan niet nog eens wat kunnen worden opgesmukt 
door extra access tags van foot=yes, horse=yes, bicycle=yes, moped=yes, 
motorcycle=yes, agricultural=yes, en wat weet ik nog allemaal, en dus 
krijg je een waaier aan mogelijkheden voor een zelfde weg, waar de tags 
enkel afhangen van het idee van de mapper op dat moment.

Dat is echt geen doen meer voor een database die we liefst met zo 
correct mogelijke data willen invullen. Vandaar dat ik het gebruik van 
cycleway en footway wil terugdringen tot fietspad en voetpad (die 
hebben namelijk ook speciale verkeersregels die nu ook volledig worden 
genegeerd wat de OSM database betreft, dus geeft dat al het eerste 
voordeel), en voor al de rest highway=path gebruiken, en naargelang de 
verbodsborden extra access tags. En dan heb je een methode gevonden 
waarbij alle mappers hetzelfde zullen doen, en waar de interpretatie 
niet meer meespeelt. En dat is zo'n voordeel in mijn ogen dat het me 
dan niet direct uitmaakt dat het dan een beetje ingaat tegen één van de 
meer gebruikelijke vormen van het gebruik van cycleway en footway.

Ben

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

Re: [OSM-talk-nl] relatie bij punt

[Ben Laenen]

2009/6/9 Lennard l...@xs4all.nl:
 Christiaan Welvaart wrote:

 Als je echt 3 verschillende kanten op kan fietsen op die rotonde,
 misschien moet je dan een fietsknooppunt relatie op de hele rotonde (het
 fietspad) zetten?

 Dat vind ik wel een prikkelende uitspraak!

 Een knooppunt dus niet beperken tot 1 (of soms meer) nodes, maar ook
 kunnen zetten op meerdere wegen binnen een kruisingsvlak. Dan kunnen de
 knooppuntroutes zelf aansluiten op dat complex van wegen, en hoef je
 niet meer moeilijk met role=forward/backward te werken rond het
 knooppunt zelf.

Bah, dat vind ik maar een luie oplossing. Als je de exacte situatie
kan taggen met forward en backward roles en de juiste relaties op de
juiste ways te zetten, dan zal de situatie veel duidelijker zijn aan
de hand van de kaart. Al begrijp ik dat sommigen het maar moeilijk
gedoe vinden met die forward en backward roles en soms vier of meer
knooppuntrouterelaties op sommige ways.

 Blijven de praktische dingen over: hoe kunnen we dit renderen, gaan
 routers dit begrijpen, en gaan andere data-gebruikers erin mee?

Wel, renderers gaan het alleszins niet begrijpen als je rcn_ref=12 zet
op de ways, want dan denkt die dat het niet gaat om een knooppunt maar
om een rcn route met ref=12.

Ben

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

Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2

[Ben Laenen]

Christiaan Welvaart wrote:
 Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan
 beschrijven op de wiki:

 access:motor_vehicle:backward=no
 access:motorcycle:backward=yes
 access:moped:backward=yes
 access:mofa:backward=yes

 Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat
 bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de
 way staat. Het access: voorvoegsel kan eventueel weggelaten worden.

Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd 
fietsers wordt dan: oneway=yes + bicycle:oneway=no

Die backward/forward syntax zal ook wel eens ingevoerd worden, maar is wat 
minder leesbaar wat mij betreft, en kan volgens mij meer gebruikt worden moest 
de straat ook echt verbodsborden hebben langs één zijde en geen gewone 
enkelrichtingsborden.

  - In Nederland wordt een vrijliggend fietspad getagd als een losse
  cycleway. Maar dan weet de navigatie software niet dat je daar wel
  verplicht bent om te fietsen.

 Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit
 moet ik nog duidelijk op die wiki pagina zetten.

Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die 
wegen in bepaalde situaties die categorieën juist wel toelaten. Ken de exacte 
regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of 
voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad 
(ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen).

Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een 
fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien.

Maar dan is het natuurlijk belangrijk om verplichte fietspaden als dusdanig te 
mappen, en al wat niet als een verplicht fietspad aangeduid wordt ook niet zo 
te mappen, zodat dat bospaadje vijftien meter parallel naast de weg niet 
aanzien wordt als verplicht fietspad door de routeplanner. Een tag als 
highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd 
is is dan een goed idee.


Maar ja, ik ga er ook van uit dat routeplanners slim genoeg worden om 
verkeersregels van elk land te kunnen begrijpen. Als een weg motorcar=no is 
(vertaling van het verbodsbord met auto-icoon naar tag) dan moet die bv. weten 
dat brommobielen of motorfietsen met zijspan ook niet op de weg mogen. Want 
het expliciet taggen voor elk mogelijk voertuig voor zo'n bord zoals 
http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging op het 
eerste zicht schijnt te doen is geen goed idee, want zoiets krijg je al met 
moeite foutloos opgesteld in zo'n tabel en regelmatig denk iemand aan een 
ander regeltje waardoor voor een verkeersbord ineens een nieuwe extra tag 
nodig is (voor het verbodsbord met een auto: zie brommobielen, quads, 
motorfietsen met zijspan etc, die volgens de wikipagina zijn toegelaten als je 
geen impliciete regels invoert), en je maakt het mappers ook niet makkelijk 
als je hen alles expliciet laat taggen.

Ben


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

Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2

[Ben Laenen]

Eugene van der Pijll wrote:
 Ben Laenen schreef:
  Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd
  fietsers wordt dan: oneway=yes + bicycle:oneway=no

 Volgens de wiki is in dit geval oneway=yes cycleway=opposite ook een
 oplossing.

Maar dan zit je met problemen als ook andere voertuigen tegen de richting 
mogen (in België bromfietsers klasse A, ofwel moped_A:oneway=no)

 In dat geval is foot=no natuurlijk een slecht idee: als voetgangers de
 weg (of de berm) mogen gebruiken, kan je foot=no weglaten. Maar
 bicycle=no op de hoofdweg is in dit geval wel de goede tag, volgens mij.

Alleen mogen die ook de weg op: fietspad onderbroken bijvoorbeeld, of als je 
moet afslaan. Ook als het verplicht fietspad links ligt hoef je die niet te 
volgen als je daar een reden voor hebt (wederom Belgische regels, weet niet 
in hoeverre alles naar Nederland kan gebracht worden).

  Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er
  een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht
  aanzien.

 Een routeplanner kan niet raden of een fietspad verplicht (rond blauw
 bord met fiets) of onverplicht (rechthoekig zwart bord met FIETSPAD)
 is.

Dan zorg je ervoor dat die het kán raden door ze anders te taggen. Me dunkt 
dat er ook nog andere regels zijn die verschillen tussen verplicht en 
onverplicht fietspad, dus het is sowieso zinvol van dat te doen.

  Een tag als
  highway=cycleway voorbehouden voor een fietspad dat als dusdanig
  bewegwijzerd is is dan een goed idee.

 Slecht idee. Fietpaden die aangegeven worden door het bord onverplicht
 fietspad zijn ook fietspaden.

Ik doel vooral op het feit dat een pad vaak als cycleway wordt ingegeven 
terwijl het geen fietspad is (verplicht of onverplicht).

Ben


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

Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2

[Ben Laenen]

Christiaan Welvaart wrote:
 Een routing app moet dan intern een lijst van transportmiddelen gaan
 aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk,
 dus schrijf maar een voorstel en zet het op de wiki (country specific
 access tag semantics for routing?), dan kunnen we kijken of mensen dit een
 goed idee vinden.

country specific access tag semantics for routing, dat bestaat al hoor. 
Zoiets moet niet worden voorgesteld want ieder land doet het al. In land X 
bevat vehicle ruiters, in land Y niet. In land X mogen voetgangers op 
highway=cycleway, in land Y niet. access=destination is van toepassing op 
fietsers in land X, en niet in land Y. In België is moped zowel voor 
bromfietsers klasse A (snorfietsen) en B, en in NL willen jullie het Duitse 
mofa invoeren voor snorfietsen, en moped voor enkel onze klasse B, enzovoort.

En aangezien het al bestaat en routers al een lijst hebben van regels voor elk 
land, kan je er beter ook maar deftig gebruik van maken om tagging regels in 
je land niet nodeloos moeilijk te maken om het te proberen in te passen in een 
internationale omgeving, een utopie die niet mogelijk is omdat het al anders 
is in elk land.

Ben


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

Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2

[Ben Laenen]

Christiaan Welvaart wrote:
 Je zegt hier nu wel dat 'het al bestaat', maar waar kan ik dit op de wiki
 teruglezen? En dan heb ik het niet over verschillende beschrijvingen voor
 elk land-project want dat noem ik eerder chaos.

Welja, elk land heeft zijn eigen verschillende regels en dus bestaat het de 
facto. Of dat nu ergens expliciet in de wiki staat geschreven of niet, 
impliciet staat het er alleszins op alle landenpagina's.

Maar als je het wil proberen veranderen, ik hou je niet tegen. Maar ik denk 
dat je een utopie probeert te bereiken daarmee. Voertuigtypes ga je nooit 
kunnen gelijk trekken over de hele wereld. Wat hier onder motorfiets is, is 
ergens anders een auto, of een bromfiets die een motorfiets is in een bepaald 
land. Dat is probleem 1 dus. Probleem 2 is dat de verkeersborden net iets 
andere betekenissen hebben in sommige landen. Neem nu bijvoorbeeld 
access=destination: in België betekent het dat voetgangers, fietsers en 
ruiters onverminderd toegang hebben tot die weg. Moeten we dan steeds 
expliciet foot=yes, bicycle=yes en horse=yes toevoegen enkel omdat die in land 
X niet de weg inmogen bij access=destination, terwijl zo'n situatie hier niet 
eens kán voorkomen? En terwijl veel mensen hier niet eens weten dat fietsers 
en ruiters daar altijd inmogen, en die die extra tags zo zouden vergeten.


  En aangezien het al bestaat en routers al een lijst hebben van regels
  voor elk land, kan je er beter ook maar deftig gebruik van maken om
  tagging regels in

 Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij
 en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek.

Sorry, ik wou zeggen ... en routers al een lijst *zouden moeten* hebben van 
regels voor elk land 

Maar ik zie liever een OSM-library die routers en wat weet ik nog allemaal 
kunnen gebruiken zodat al die regels op één plaats zijn samengebracht.

Ben


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

Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2

[Ben Laenen]

Eugene van der Pijll wrote:
 Christiaan Welvaart schreef:
  Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een
  pad staat (door de highway tag of anders) dan is het een verplicht
  fietspad, als er bicycle=yes op staat dan niet.

 Dat is volgens mij niet wat designated betekent. Het betekent bedoeld
 voor, aangewezen voor; in OSM-termen: wat er op het bordje staat.

Wel, niemand weet het echt wat access=designated betekent. In Duitsland wisten 
ze het ook niet meer omdat iedereen het anders toepaste en maken ze het nu nog 
wat moeilijker met een access=official tag in te voeren.

  Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een
  routing app dit verschil niet te maken.

 +1.

 Zelfs als er een andere manier is om hetzelfde te taggen: een bicycle=no
 tag op de hoofdrijbaan is nooit verkeerd; er mag namelijk niet gefietst
 worden.

Kijk, als het fietspad verplicht is, dan is dat een eigenschap van dat 
fietspad, en moet je dat oplossen met tags op dat fietspad. Voor België is 
highway=cycleway genoeg om te zeggen dat er een verplicht fietspad is zodat 
als een router zo'n weg parallel ziet aan een andere weg, die kan weten dat 
fietsers niet via de weg kunnen (maar ook nog kan weten dat die fietser in 
bepaalde gevallen ook nog wel de rijbaan opmag moest de situatie daarom vragen 
-- tenzij er een verbodsbord staat om een of andere reden, waarbij je dus 
bicycle=no nodig hebt).

Ben


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

Re: [OSM-talk-nl] Saaie, disfunctionele website

[Ben Laenen]

Stefan de Konink wrote:
 On Fri, 24 Jul 2009, Ante wrote:
  Ik loop niet te janken, ik vind de vorige website veel beter dan wat er
  nu is. Mag dat niet gezegd worden?

 Daar zijn heel wat mensen niet mee eens, vooral die hun eigen projecten
 niet zagen op de blog, beginners geen houvast biedde en data doneurs geen
 richting of contact adres boden.

Neemt toch niet weg dat de vormgeving toch wel een stuk beter kan. Als je nu 
naar de site gaat krijg je een bijna volledig leeg blauw scherm, het soort 
scherm waarbij ik denk even geduld, de pagina is nog aan het laden, alleen 
verandert die niet meer. En misschien een vijfde van het hele scherm wordt 
gebruikt door een droog lijstje met links met tegen dat lichtblauw staande 
pastelkleuren. Het ziet er gewoon niet interessant uit. Zet minstens toch een 
mooi gerenderde kaart in het midden, verander een paar links naar icoontjes, 
zet er een klein introductietekstje bij, gebruik meer van de pagina dan enkel 
een klein kadertje linksboven, en herdenk de kleuren. Maar dat kost wat werk 
uiteraard, zeker als het iets dynamisch moet worden, en er moet eerst iemand 
naar voor komen die dat kan en wil doen natuurlijk.

Of het nu functioneel meer te bieden heeft dan voordien, ik denk niet dat de 
discussie daarrond draait hier.

Ben


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

Re: [OSM-talk-nl] Goede tag voor bos

[Ben Laenen]

fabermich...@planet.nl wrote:
 Nu blijkt er dus (min of meer) overeenstemming te zijn over landuse=forest.
  Naar mijn mening is deze echter fout. Van niet beheerd tot veel beheerd:
 Oerbos
 normaal bos
 bosbouw/plantages
 
 Voor Nederland zou je dan uitkomen op:
 Natural=wood
 landuse=wood

landuse=wood is volgens mij geen aanvaarde tag. Hij zal waarschijnlijk wel 
gerenderd worden, maar bij mijn weten is het natural=wood óf landuse=forest. 
Die tussentag is er enkel gekomen door verwarring van de twee tags. Er 
bestonden diverse bots in het verleden die door de OSM data gingen en al de 
landuse=wood tags omzetten naar één van de twee ander.

 landuse=forest

En dat gezegd zijnde, op dit moment worden (in de praktijk) zowel natural=wood 
en landuse=forest volledig door elkaar gebruikt (wat er ook over geschreven is 
in diverse kanalen en het in theorie zou moeten zijn). Waarom ze verschillend 
renderen is me dan ook een raadsel.

Er moet inderdaad eens verschil worden gemaakt tussen verschillende soorten 
bos, maar dan niet door te kijken naar deze twee tags. De meeste mappers 
gebruiken enkel hun persoonlijke voorkeurstag voor die hoop bomen die ze zien 
(ze nemen één van de twee en taggen dan alle bossen daarmee).

Dit hele gedoe gaat enkel opgelost raken door extra tags in te voeren, want 
aanpassen wat nu bestaat gaat zijn tijd wel kosten -- om maar te zwijgen van 
de hele onduidelijkheid waar dan wel de grens ligt tussen de twee, want 
mappers die wel verschil maken tussen de twee hebben daar vaan hun eigen 
mening over. Net zoals de volledige landgebruik- of bodembedekkingmaterie gaat 
dit bosgedoe eens deftig verbeterd moeten worden, maar dan dus wel met nieuwe 
tags, omdat de bestaande duidelijk niet goed gedefinieerd zijn geweest.

Ben

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

Re: [OSM-talk-nl] Goede tag voor bos

[Ben Laenen]

fabermich...@planet.nl wrote:
 Ik zit dan alleen nog met een park. Kan dat leisure=park worden. Ik las dat
  ergens in een vorige mail, maar kan die zo gauw niet weer vinden. Dan
  zitten we weer met het verschil tussen gras en bomen in een park
  (type=grass/trees).

leisure=park en tags voor bossen zijn niet mutueel exclusief. Je kan ze 
allebei op dezelfde plek gebruiken. Dus map de rand van het park met 
leisure=park, en al de bomen, grasvelden en al het andere dat je in het park 
vindt kan je met de nodige landuse=forest en natural=grass invullen. Krijg je 
bijvoorbeeld dit: 
http://tile.openstreetmap.nl/?zoom=16lat=51.1673lon=4.43363layers=B0FFF

We doen hetzelfde met bijvoorbeeld leisure=nature_reserve.

Ben 

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

Re: [OSM-talk-nl] Ditchen OpenLayers voor kHTML

[Ben Laenen]

Stefan de Konink wrote:
 Hoi,
 
 
 Wellicht hebben jullie het op de devlijst gezien; er is een nieuwe
 browser based tile engine in town het heet: khtml[1]
 
 Om mensen die het nog niet gezien hebben even van hun stoel te laten
 vallen: http://www.khtml.org/iphonemap/simple.html
 
 
 Ja smooth zoom, snel scrollen, eigenlijk alles wat je wilt. Ik vraag me
 dus af of we dat niet beter kunnen gebruiken voor de
 tile.openstreetmap.nl pagina als www achtergrond.

Eigenlijk het enige pluspunt dat ik kan zien is dat sneller zoomen. Het valt 
wel nog steeds te zien hoe snel die tiles gedownload worden om het effect te 
krijgen en vier op vijf zoomlevels krijg je uitgerokken en geblokte tiles 
waardoor het meestal ook niet erg aantrekkelijk is.

Dus ik begrijp niet zo waarom we hiervoor van onze stoel moeten vallen. Dat 
sneller zoomen (zijnde dat je in één keer twee keer kan scrollen met je muis 
i.p.v. te moeten wachten tot de eerste zoomactie ongeveer afgerond is) zou 
waarschijnlijk ook wel kunnen geïmplementeerd worden in openlayers zeker, en 
zijn die extra zoomlevels nu echt nodig als er toch geen deftige tiles kunnen 
getoond worden? Tenzij je het wil doen als bing en het gebruikt om wat stapjes 
tussen de zoomlevels in te bouwen, maar dan moet je dus niet stoppen op elk 
van die tussenstapjes.

Ben

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

Re: [OSM-talk-nl] Kassen

[Ben Laenen]

Floris Looijesteijn wrote:
 of zo:
 
 http://wiki.openstreetmap.org/wiki/Proposed_features/greenhouse_horticultur
 e
 
 niet dat ik die tag echt goed gekozen vind maar warehouse is volgens mij
 iets heel anders. het is toch glasshouse of greenhouse?

Opgelet, landuse=greenhouse_horticulture is niet voor de serres zelf, maar ook 
voor al het land en de gebouwen errond. Om die reden zal die tag ook hetzelfde 
renderen als landuse=farm

Ikzelf heb al meermaals building=greenhouse gebruikt voor de serre zelf. Voor 
mij lijkt dit me de enige manier om verschil te maken tussen soorten gebouwen. 
building=station wordt bvb al anders gerenderd in Mapnik dan building=yes.

Ben

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

Re: [OSM-talk-nl] Sporen in NL

[Ben Laenen]

Cartinus wrote:
 On Sunday 18 April 2010 21:21:01 Floris Looijesteijn wrote:
  Hmm, volgens mij stel je het wel heel eenvoudig voor. Bij de stations
  vind ik het inderdaad mooi als het niet is samengevoegd maar op de lange
  stukken...
  Van Amsterdam tot aan Schagen is het bijvoorbeeld dubbel spoor maar is
  OSM ligt daar maar 1 way. Dat kan wat mij betreft zo blijven.
 
 Ik zag vanochtend tussen Maarssen en Breukelen twee ways voor vier sporen.
  Op de westelijke way zit een een relatie voor de stoptrein en op de
  oostelijke way zitten relaties voor de IC's.
 
 De logica ervan kan ik niet helemaal volgen. M.i. gebruik je of 1 way met
  een tracks=4 tag of 4 ways, zodat je de relaties op de sporen kunt leggen
  waar de treinen werkelijk rijden: stoptreinen op de middelste sporen, IC's
  op de buitenste (meestal op dat traject).

In België is het grootste deel van het land zo gemapt dat twee sporen als één 
way worden teruggebracht (op enkele plekken is er wel meer detail zodat één 
way = één spoor). Maar eigenlijk worden de spoorlijnen gemapt als één way. 
En één spoorlijn kan twee sporen bevatten, en niet meer. Dus als tussen 
Antwerpen en Brussel vier sporen lopen, dan zijn dat twee spoorlijnen (in 
België krijgen spoorlijnen nummers, in dit geval zijn dat L25 en L27). Tussen 
Brussel en Leuven liggen ook vier sporen, maar in OSM zijn dat drie ways. De 
reden daar is dat de middenste twee een spoorlijn zijn (L36N) en de buitentste 
twee ook één (L36). Dus in feite wordt een spoorlijn gezien als een gewone weg 
die ook meerdere rijstroken kan hebben, maar die we ook niet afzonderlijke 
ways geven. Misschien spelen er gelijkaardige argumenten mee in Nederland?

Maar ik ga er ook mee akkoord dat in de beste situatie één way één spoor 
voorstelt. Maar daarvoor heb je dus zeer gedetailleerde informatie nodig en 
die is ook niet altijd direct voorhanden. En de sporen zelf zijn ook nogal 
moeilijk te mappen met een gps :-)

Ben

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

Re: [OSM-talk-nl] auteursrechten op wegenkaarten - gerechtelijke uitspraak

[Ben Laenen]

Rob wrote:
 Ik mis nog een conclusie in het blog artikel.
 
 Zijn er btw nog andere rechten van toepassing ?

Dat is ook mijn vraag: wat met het databankrecht? Daar is geen creativiteit in 
het werk bij nodig.

En als het databankrecht ook niet meetelt, dan werpt dat ook weer een heel 
ander licht op de ODbL-discussie :-)

Ben

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

Re: [OSM-talk-nl] Correctiewerk gerelateerd aan 3dshapes

[Ben Laenen]

stegg...@steggink.org wrote:
 Ik zag zojuist dat user ijsb diverse correctiewerkzaamheden uitvoert
 [1], door o.a. paden e.d. van landuse vlakken (3dshapes import) los te
 trekken. Deze werden door anderen incorrect ingebracht. Zie bijv. [2].
 
 [...]

 Een oplossing hiervoor is niet 1-2-3 te geven. Ik zou het in ieder
 geval niet weten. Zou het niet een idee zijn om met RichardF te
 babbelen om een soort lagenstructuur aan Potlatch toe te voegen, zodat
 bijv. wegen en landuse data onafhankelijk van elkaar bewerkt kunnen
 worden? Als beide lagen aangevinkt worden, kunnen ze tegelijk
 bewerkt worden, en kunnen ook nodes, e.d. hergebruikt worden.

Iets wat ik mis in Potlatch is zoiets als wat de ctrl toets doet in JOSM: 
ervoor zorgen dat punten die je toevoegt nergens aan worden vastgehangen. Voor 
zover ik weet bestaat dit niet in Potlatch en is vaak de enige manier om dat 
op te lossen om de weg eerst ergens anders te leggen en dan te verplaatsen 
naar waar ze moet komen...

Ben

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

Re: [OSM-talk-nl] Wandelroutes

[Ben Laenen]

Rob wrote:
 Op 13 augustus 2010 13:16 heeft  stegg...@steggink.org het volgende
 
 geschreven:
  V.w.b. de rendering met kleuren: de kleur kan wel als attribuut in de
  data worden opgeslagen (omdat die ook een bepaalde aanduiding is).
  Daarmee kan een custom rendering worden gemaakt van een veel hogere
  kwaliteit, dan degene die op routeyou wordt aangeboden.
 
 zoals als  ref:color=red

colour met een u omdat de tags in Brits Engels zijn. Er zijn in het 
verleden al bots bezig geweest om color in colour te veranderen.

Ben

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

Re: [OSM-talk-nl] Poller taggen

[Ben Laenen]

Andre Engels wrote:
 Zoals al gemeld, barrier=bollard, en dan eventueel
 voertuigtype=yes/no. Default voor een bollard is access=no, foot=yes,
 bicycle=yes (dus: fietsers en voetgangers kunnen erlangs, andere
 weggebruikers niet).

Niet akkoord: default voor bollard is al het smal verkeer, i.e. alles dat 
per default op een highway=path kan: foot, bicycle, moped, horse.

Ben

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

Re: [OSM-talk-nl] Highway=services of highway=service op ways van verzorgingsplaatsen?

[Ben Laenen]

Colin Smale wrote:
   Gisteren heeft gebruiker xxx heel veel (alle?) wegen binnen de
 verzorgingsplaatsen aan de Nederlandse snelwegen omgetagd van
 highway=service naar highway=services. Gevolg is dat de wegen nu
 onzichtbaar zijn op de kaart, hoewel de eenrichtingspijltes er nog wel
 staan. Ik kan me ook voorstellen dat routing deze wegen ook zal negeren.

Hij zal verward zijn door de definitie van highway=services. highway=services 
is inderdaad voor die snelwegparkings (het hele gebied, of een node ergens in 
het midden als je het niet nauwkeurig kan mappen), maar de wegen moeten wel 
met highway=service getagd blijven.

Ben

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

Re: [OSM-talk-nl] Startpunt lwn Wandelroute

[Ben Laenen]

2010/8/27  rob...@elsenaar.info:
 Zoals de meesten inmiddels wel weten, ben ik al enige tijd bezig om de
 Nederlandse wandelroute project in een stroomversnelling te brengen.

 Om de mogelijkheden van het verbeteren van de open wandelkaart te vergroten
 missen de lwn-relaties een belangrijk gegeven. In geen enkele lwn-relatie is
 te ontdekken waar je de wandeling kunt beginnen. Uit de praktijk weten we
 dat rondgangen op 1 of meer plaatsen begonnen kan worden. Er is daar plaats
 om te parkeren en er staat minimaal een wegwijspaal en in veel gevallen een
 informatiebord.


Ik denk dat ik in België in een paar wandelroutes wel een node in hun
relaties heb gezet met role start. Lijkt me de makkelijkste manier
ook.


 In de kaart wil ik de mogelijkheid bieden om op bepaalde zoomlevels niet de
 gehele route te renderen, maar alleen de startpunten. Dit zal de
 overzichtelijkheid van de wandelkaart, op het moment dat 'alle' routes
 gemapt zijn, ten goede komen.

En wat toon je dan als er geen echt beginpunt in een route is?

Ben

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

Re: [OSM-talk-nl] Startpunt lwn Wandelroute

[Ben Laenen]

rob...@elsenaar.info wrote:
 En wat toon je dan als er geen echt beginpunt in een route is?
 
 Iki denk dat dat uitzonderingen zijn. Heb jij ergens een voorbeeld
 waar een route is met alleen naamloze paaltjes en nergens op de route
 een Naamplaatbord of een informatiebord?

De meeste routes hebben een of meerdere beginpunten, akkoord. Maar ook één 
route die er geen heeft is genoeg om ermee rekening te houden.

Het probleem is trouwens ook dat je niet altijd dat beginpunt kan herkennen, 
en je het enkel te weten komt door de kaartjes te bekijken van de mensen die 
die routes gemaakt hebben. Iets wat we dus niet mogen... Je kan natuurlijk 
slim nadenken en wel een beredeneerde gok maken waar het beginpunt ligt, maar 
dan mappen we onzekerheden...

Ben

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

Re: [OSM-talk-nl] BV het Pieterpad

[Ben Laenen]

rob...@elsenaar.info wrote:
 Met aanwezige tracks plan ik graag een paar avondjes o ze in te brengen.
 :-)

Wil wel eens weten hoe je dat juist gaat mappen met enkel een track. Hoe weet 
je dan wat er zich in werkelijkheid bevindt (pad, zandweg, verharde weg, 
misschien zelfs trappen)?

Ben

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

Re: [OSM-talk-nl] BV het Pieterpad

[Ben Laenen]

ce-test, qualified testing bv - Gert Gremmen wrote:
 De eerste etappe zit erin. Pieterburen Winsum. Dat was een makkie.
 Bijna alleen verharde wegen.
 Ik kies ervoor om voorlopig alle etappes een aparte relatie te geven, en
 daarna het hele Pieterpad in een superrelatie te brengen.
 http://openwandelkaart.nl/?zoom=13lat=53.34719lon=6.5032layers=B000FT
 FTTF
 
 Dat voorkomt een heleboel puzzelwerk als er fouten in de relatie komen.
 Ik denk dat we dezelfde aanpak moeten kiezen voor de LAW als bij
 de lange snelwegen.
 Bij de nationale fietspaden heb ik al gemerkt dat het behoorlijk
 lastig is vast te stellen of de route er compleet inzit, omdat de
 relatie
 van het pad soms duizenden ways omvat. Die moeten we misschien ook eens
 omkatten.

Integendeel. Niks zo makkelijk als controleren of een wandelroute volledig is, 
omdat er geen speciale situaties zijn zoals bij fietsroutes waar de route heen 
en terug niet overal dezelfde is. Zelfs de relatie-editor in JOSM kan dit al 
laten zien.

Je maakt het jezelf zelfs moeilijker als je opsplitst in allemaal stukjes van 
20km, want wil je dan controleren of de route mooi op elkaar aansluit dan ga 
je die allemaal één voor één moeten testen, met manuele tests of de plekken 
waar twee relaties op elkaar aansluiten wel in orde zijn.

Ben

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

Re: [OSM-talk-nl] RFC - Roundabout Priority t.b.v. verkeerspleinen

[Ben Laenen]

Dit lijkt me vrij nutteloos als tag. Het zit in de definitie van
rotonde dat wie op de rotonde rijdt voorrang heeft, en iets is een
rotonde als het rond blauw bord met pijlen er staat. En in OSM zegt de
tag junction=roundabout dat het een rotonde is. Een gewoon
verkeersplein heeft geen junction=roundabout tag.

Bijgevolg: heb je een verkeersplein met junction=roundabout: rotonde
met voorrang voor wie op die rotonde rijdt.
Een verkeersplein zonder junction=roundabout is niets speciaals en
daar geldt dus de normale voorrang van rechts.

Ben


2010/9/27 Colin Smale colin.sm...@xs4all.nl:
  Ik heb een proposal gemaakt voor de nieuwe tag
 roundabout=priority_to_right voor gebruik op verkeerspleinen.

 Details op
 http://wiki.openstreetmap.org/wiki/Proposed_features/Roundabout_Priority -
 op/aanmerkingen welkom!

 Het voorstel is uiteraard ook via de wereldwijde tagging-list aangekondigd.

 Colin

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

Re: [OSM-talk-nl] RFC - Roundabout Priority t.b.v. verkeerspleinen

[Ben Laenen]

Colin Smale wrote:
 De discussie hier en in de tagging-list lijkt neer te komen op de volgende
 vraag: Is een verkeersplein een subtype van roundabout, of is het een
 zelfstandig kruispunttype? Iedereen lijkt het erover eens te zijn dat het
 een zelfstandig kruispunttype hoort te zijn. Mijn uitgangspunt was dat de
 gemiddelde Nederlander het eerder zal zien als een subtype van rotonde,
 maar blijkbaar ben ik in de minderheid.

Het zit hem natuurlijk in de exacte definitie. In België is het begrip 
rotonde gedefinieerd als: weg waarop het verkeer in één richting geschiedt 
rond een aangelegd middeneiland en gesignaleerd met verkeersborden D5 en 
waarvan de toegangswegen voorzien zijn van verkeersborden B1 of B5. (D5 is 
het rond blauw bord met pijlen in tegenwijzerszin, B1 is de omgekeerde 
driehoek, en B5 is het stopbord.). Ik neem aan dat het begrip in Nederland op 
een gelijkaardige manier is gedefinieerd.

Maar in België hebben we het erg vaak over een rondpunt. Dat heeft geen 
definitie in de wegcode, maar het omvat eigenlijk alles waar het verkeer in 
een rondje gaat. Een rotonde is dus een speciaal soort rondpunt.

En daar zit je zelf dus verkeerd: verkeersplein is geen subtype van rotonde, 
maar het is omgekeerd: rotonde is een speciaal verkeersplein. En het is nu 
juist een rotonde dat getagd wordt met junction=roundabout. Als je 
verkeerspleinen tegenkomt die daarmee zijn getagd en die geen rotondes zijn, 
dan is dat een fout in de kaart. En bijgevolg is het dus ook zo dat de 
voorrang van rechts steeds geldt, behalve wanneer je een junction=roundabout 
tag hebt.


 Misschien is het beter om in plaats van dit voorstel een nieuw voorstel te
 doen voor een nieuw kruispunttype zoals junction=verkeersplein (maar dan
 in het engels). In de tagging-list is de term traffic circle genoemd.
 Zou er meer steun zijn voor junction=traffic_circle in plaats van een
 hele nieuwe tag?

Om te beginnen moet je komen met een goeie definitie van verkeersplein. En 
dat kan ook wel eens een leuke discussie worden :-)

Ben

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

Re: [OSM-talk-nl] RFC - Roundabout Priority t.b.v. verkeerspleinen

[Ben Laenen]

Maarten Deen wrote:
 Vind ik wel. Je hebt zelf al aangegeven dat er in de Nederlandse
 wetgeving geen verschil bestaat tussen een verkeersplein en een rotonde.

Waar heb je dat vandaan?

Ben

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

Re: [OSM-talk-nl] RFC - Roundabout Priority t.b.v. verkeerspleinen

[Ben Laenen]

Maarten Deen wrote:
 Mijn vraag is dus: waarom wil je een verschil aanbrengen tussen rotonde
 en verkeersplein, als dat verschil op de grond niet te zien is.
 Want ook verkeerspleinen die in Wikipedia genoemd worden (Joure,
 Velperbroek) worden met een bord voor een rotonde aangeduid en zijn
 voorrangsrotondes.
 Dan worden de niet-voorrangsrotondes nog niet eens genoemd als
 verkeersplein.
 
 Dus waar het voorstel roundabout=priority_to_right nog enige informatie
 toevoegt, zie ik de toegevoegde waarde van een onderscheid tussen een
 rotonde en een verkeersplein helemaal niet.


Oké, volgens mij zitten we met verschillende definities van verkeersplein, 
waardoor ik soms kop noch staart krijg aan deze discussie. Dus misschien een 
rondje om te weten wie wat bedoelt?

Ik versta onder verkeersplein alles waar het verkeer in tegenwijzerszin rond 
iets moet rijden. Er is gerust vanalles mogelijk op verkeerspleinen, zoals 
verkeerslichten. Zonder verkeersborden of -lichten geldt de gewone voorrang 
van rechts.

Rotondes zijn een speciaal soort verkeersplein, en onderscheidt zich omdat er 
een rond blauw verkeersbord met pijlen in tegenwijzerszin staat.


Bijgevolg mijn visie op OSM-tags: junction=roundabout is enkel voor rotondes, 
en impliceert een voorrang voor wie op de rotonde rijdt. Een verkeersplein dat 
geen rotonde is heeft die tag niet en dus is het standaard voorrang van rechts 
(tenzij er andere verkeersborden te vinden zijn, die dan weer op hun beurt 
anders kunnen getagd worden)

Ben

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

Re: [OSM-talk-nl] RFC - Roundabout Priority t.b.v. verkeerspleinen

[Ben Laenen]

2010/9/28 Maarten Deen md...@xs4all.nl:
 Ben Laenen wrote:
 Oké, volgens mij zitten we met verschillende definities van
 verkeersplein, waardoor ik soms kop noch staart krijg aan deze discussie.
 Dus misschien een rondje om te weten wie wat bedoelt?

 Even voor mijn (en misschien andermans) duidelijkheid: jij bent Belg als ik
 me niet vergis?

Ik pleit schuldig :-)

Het ziet er dus naar uit dat ik dacht dat de definitie van rotonde in
België overeenkwam met die in NL. Rotonde in België is dus als je de
borden voor verplicht rondgaand verkeer (blauw rond met pijlen) samen
met borden op de toegangen dat je voorrang moet geven op de
toegangsswegen). Op een Belgische rotonde heeft dus altijd het verkeer
op de rotonde voorrang. En dit komt dus overeen met de OSM-definitie
van junction=roundabout.

Maar rotonde is dus blijkbaar ruimer in NL en lijkt een beetje op wat
we hier rondpunt noemen (hoewel die term niet gedefinieerd is in onze
wegcode).

Rondpunten die geen rotonde zijn komen trouwens vaak voor hier. In OSM
hebben deze dan ook geen junction=roundabout tag.


 Ik ben het eens met junction=roundabout is enkel voor rotondes, maar niet
 met impliceert een voorrang voor wie op de rotonde rijdt.

Tja, daar heb je de osm-regels niet mee, die expliciet vermelden dat
voor junction=roundabout voorrang geldt voor wie op de rotonde rijdt.
En het probleem zat hem er dus in dat je roundabout als rotonde hebt
vertaald in NL en dat dus niet helemaal hetzelfde is, en het mij dan
ook nog eens serieus in de war bracht met ons begrip van rotonde.

Hoe dan ook, je moet natuurlijk zelf weten wat je wil doen in NL, daar
heb ik als Belg niks aan te zeggen :-) Al gaat mijn voorkeur dan toch
naar dat je iets invoert als junction=roundabout voor voorrang op
rotonde en junction=traffic_circle voor de andere rotondes...

Ben

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

Re: [OSM-talk-nl] RFC - Roundabout Priority t.b.v. verkeerspleinen

[Ben Laenen]

Maarten Deen wrote:
 
 Zijn er ook situaties waar wel een blauw bord met pijlen staat maar
 waar geen voorrang verleend hoeft te worden?

Goeie vraag, en ik zie niks in de wegcode dat dat verbiedt. Alleen moet ik het 
eerste dergelijk geval nog tegenkomen...

Maar moest het voorkomen, dan is het opnieuw geen rotonde.


  Rondpunten die geen rotonde zijn komen trouwens vaak voor hier. In OSM
  hebben deze dan ook geen junction=roundabout tag.

 Heb je voorbeelden waar ze zijn? Ik kan me namelijk niet herinneren er
 eentje tegengekomen te zijn.

Een bekend rondpunt in België dat geen rotonde is is het rondpunt van 
Wommelgem: http://osm.org/go/0epb...@w- -- het verkeer wordt hier nu volledig 
geregeld met verkeerslichten.

Ietsje kleiner: http://osm.org/go/0EpZLb4Ki- (Draakplaats, Tramplein) -- 
verkeer wordt errond geleid met ronde blauwe borden met gebogen pijl naar 
rechts. Verkeer op het rondpunt heeft voorrang, en op elke toegangsweg staat 
de omgekeerde driehoek.

Iets van een gemiddeld formaat daar vlakbij: http://osm.org/go/0EpZLklej- 
(midden op Cogels-Osylei) -- verkeer wordt errond geleid met ronde blauwe 
borden met pijl naar rechts. Hier geldt gewone voorrang van rechts 
(uitgezonderd tram die altijd voorrang heeft natuurlijk).

Kleinere voorbeeldjes zijn die in deze straten http://osm.org/go/0EpbAaKIF- -- 
Het middeneiland is daar erg klein (niet meer dan een meter in doorsnede), en 
verkeer wordt errond geleid met ronde blauwe borden met pijl naar rechtsonder.


 Ik je zult dat dan ook overal moeten gaan invoeren. Vooral de
 verschillende applicaties die kaarten voor navigatieapparatuur maken.

En in België willen we dan natuurlijk ook niet dat de mevrouw van de gps het 
heeft over een rotonde als het volgens onze regels geen rotonde is :-)


 Daarbij maakt dit het ook lastiger om vanaf luchtfoto's te mappen. Zie
 je een ronde weg op een luchtfoto, kun je veilig aannemen dat het een
 rotonde is. Maar als je je dan ook nog moet gaan afvragen of het een
 voorrangsrotonde is of niet, dan kun je eigenlijk niet meer met goed
 fatsoen een tag op die weg zetten.

Dat probleem ken ik hier al hoor :-) Als ik niet zeker weet dat het een 
rotonde is map ik enkel oneway=yes op het rondpunt.

Ben

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

Re: [OSM-talk-nl] Wochennotiz

[Ben Laenen]

Rob wrote:
 Ik heb het een half jaar geleden eens geprobeerd, na aanleiding van
 Ben Laenen z'n wekelijkse verzamel mail op de ML. Maar het kost toch
 wat werk om elke week alles bij elkaar te verzamelen.
 http://blog.openstreetmap.nl/index.php/2010/07/11/dit-was-het-nieuws-week-2
 7/

Yep, ik was ermee begonnen, maar 't had allemaal te veel tijd nodig. Om te 
beginnen moest je ook al die threads lezen waar je normaal totaal niet 
geïnteresseerd in bent...

Ben

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

Re: [OSM-talk-nl] Gegevens van kaart.almere.nl

[Ben Laenen]

2010/11/11 Peter pe...@haas-en-berg.nl:
 Dit is nog een concept.
 Wat vinden jullie? Staan er nog spelfouten of niet-lopende zinnen in?


Wat betreft spelfouten: de w mist in nauwkeurigere

En om  te muggenziften: gps is niet met hoofdletters, en
OpenStreetMapgemeenschap moet aan elkaar.

Ben

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

Re: [OSM-talk-nl] Licentie data

[Ben Laenen]

2010/11/13 F. Heinen f.heinen...@gmail.com:
 Hoi allen,
 Er is/was een discussie gaande op de IRC waar ik net zelf aan mee heb
 gedaan. De details kun je lezen
 op de IRC logs. Het ging er mij om dat ik een beeld wil hebben wat de
 haalbaarheid van de voorgestelde ODbL licentie wil zien.
 Nu lijkt het er op dat er nog maar een heel klein deel van NL al ODbL
 compliant is (
 http://osm.informatik.uni-leipzig.de/map/?zoom=13lat=52.36301lon=4.90076layers=B0
 ).
 Maar volgens mij is 90% van de data al compliant.
 Ik zou dus ook graag zien dat AND en 3DShapes accounts ook op ODbL
 geaccepteerd gezet worden.

Ah, maar kunnen die ook onder de nieuwe contributor terms gezet
worden? Dat is nog wat anders dan ODbL.

Daarnaast vind ik dat imports buiten de discussie moeten blijven. We
willen de mappers meekrijgen in het verhaal. Kwantitatief staan de
contributies van gewone mappers in de schaduw van de imports iin
Nederland, maar die mappers zijn zo veel belangrijker om dit project
gaande te houden.


 Wie kan ons wat vertellen over de planning van de licentie wijziging
 (fases)? Want ik denk dat veel mensen (incl mijzelf) dit nog niet weten.

Ik denk dat eigenlijk niemand het weet. Volgens de eerste planningen
had het al lang voorbij moeten geweest zijn.

Ben

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

Re: [OSM-talk-nl] Licentie data

[Ben Laenen]

F. Heinen wrote:
 Mappers staan zeker centraal maar wat heeft dat met de imports te maken?
 Waarom moeten die er buiten blijven? Dat zijn wel geen mappers
 maar is wel key role of de data mee gaat en daarmee of users akkoord gaan.
 Simpel, gaat AND niet akkoord (wat ze wel gedaan hebben) dan ga ik ook
 niet akkoord. Niet om de reden of ik wel of niet eens ben maar omdat ik
 mijn data bewaak en die van anderen. We zijn niet voor jan met de korte
 achternaam bezig om over een jaar of wat onze data door de drain te zien
 gaan.

Heb niet gezegd dat de imports onbelangrijk zijn. Zeker voor Nederland zou het 
rampzalig zijn om op bijna niks terug te vallen moesten de imports niet 
meekunnen naar de nieuwe CT+licentie.

Maar wat ik wel zei is dat je de evaluatie óf je naar de nieuwe licentie gaat 
vooral moet laten afhangen van de contributies van echte mappers, want zij 
dragen dit project, niet de imports.


Extreem voorbeeld voor Nederland: stel dat 3dshapes en AND naar de nieuwe 
licentie kunnen, dan heb je al ruim 90% van alle data. Wat de Nederlandse 
mappers hebben ingevoerd valt in het niets daarbij vergeleken, en voor het 
uiteindelijke resultaat lijkt het dus niet zo erg moest van die mappers nu 50% 
niet akkoord gaan of maar 10%. Het zou misschien het extra verlies van een of 
twee procent van alle Nederlandse data betekenen. Maar het moet niet gezegd 
dat je veel meer mensen voor het hoofd gaat stoten als je de data van de helft 
van de Nederlandse mappers zomaar gaat deleten.

Vandaar dat ik zeg dat je om lijstjes of visualisaties te maken voor wat 
betreft de acceptatie van de nieuwe CT en licentie de imports niet moet 
meetellen. Want in een project als OSM is de community het meest waardevolle, 
niet de data.

Ben

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