[OSM-talk-nl] Tagging laadpalen auto in Nederland

[Hugo hölscher]

Dag allemaal,

Bij het taggen van laadpalen die "los" op straat staan(voor elektrische 
auto's) loop ik tegen de naamgeving aan. Ik gebruik nu als name: de code 
die op de paal staat: bv cch0012334. Dat is een unieke code en deel van 
de ESVE (Europese officiele tag). Die lijkt langzaam te verdwijnen.


Soms zie je ook een adres waar de paal bij in de buurt staat, maar dat 
lijkt me niet beter.


Is hier al eerder over gedacht, ik heb in deze mail list niets gevonden.

Groet Hugo

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

[OSM-talk-nl] Tagging laadpalen auto in Nederland

[Hugo hölscher]

Dag allemaal,

Bij het taggen van laadpalen die "los" op straat staan(voor elektrische 
auto's) loop ik tegen de naamgeving aan. Ik gebruik nu als name: de code 
die op de paal staat: bv cch0012334. Dat is een unieke code en deel van 
de ESVE (Europese officiele tag). Die lijkt langzaam te verdwijnen.


Soms zie je ook een adres waar de paal bij in de buurt staat, maar dat 
lijkt me niet beter.


Is hier al eerder over gedacht, ik heb in deze mail list niets gevonden.

Groet Hugo



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

Re: [OSM-talk-nl] Problemen met downloaden kaarten

[Hugo hölscher]

Dag Leentje,

alternatief  als je een Android tablet of telefoon hebt is: OSMAND.  
Gratis versie heeft beperking voor het aantal kaarten wat je tegelijk 
kunt hebben (Nieuw-Zeeland is er 1) en er zijn diverse betaalde 
uitbreidingen. Het is een off-line  app. Voordeel van een tab is dat het 
lekker groot is,)


succes Hugo


Op 9-2-2019 om 09:28 schreef Leentje Osselaer:

Dankje Marc,
De site lijkt toch betalend, of kijk ik over uw optie van de gratis 
versie? Als ik  zeker de juiste formats kan downloaden, wil ik er wel 
voor betalen.

Groeten,
Leentje
*From:* Marc Zoutendijk via Talk-nl 
*Sent:* Wednesday, February 6, 2019 7:27 PM
*To:* OpenStreetMap NL discussion list 
*Cc:* Marc Zoutendijk 
*Subject:* Re: [OSM-talk-nl] Problemen met downloaden kaarten

Op 6 feb. 2019, om 16:18 heeft Leentje Osselaer 
mailto:leentje.ossel...@skynet.be>> het 
volgende geschreven:

Hallo,
Ik weet niet of ik hier aan het juiste adres ben, maar ik zou een 
kaart van Nieuw-Zeeland willen downloaden, waar we volgende week 
naartoe gaan. Ik krijg echter steeds het volgende bericht. 

Is er inderdaad iets fout met de server? Kunnen jullie helpen?



Vergeet die server zoals ook al uit een andere reactie blijkt.
Probeer deze oplossing:
https://www.velomap.org/
In de gratis versie kun je 3 downloads per maand doen. Ik gebruik zelf 
Velomap (met abonnement) voor alle landen die niet door OFM 
(OpenFietsMap) worden gedekt.

En anders kun je met deze:
https://extract.bbbike.org/
ook je doel bereiken.
En in het vervolg kun je je beter tot het forum wenden dan tot deze 
mailinglijst, want die wordt door ongeveer 5 mensen gelezen en het 
forum is wat drukker bezocht.

Groet
Marc.


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

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

Re: [OSM-talk-nl] blog.openstreetmap.nl

[Hugo Hölscher]

Is de blog soms slachtoffer van het recent ontdekte lek in PHPMailer?

Er is overigens een patch on het lek te dichten.

Groet Hugo


Op 18 feb. 2017 12:24 schreef "Stefan de Konink" :

> Ps maar als er een vrijwilliger komt die het in de lucht wil gaan houden,
>> ga uwes ganges en draag het over.
>>
>
> Ik heb nog wat liefde gegeven aan de wordpress installatie. Hij is nog
> niet weg.
>
> --
> Stefan
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
>
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] App toont voedselveiligheid Nederlandse lunchrooms

[Hugo Hölscher]

Er zijn meer van dat soort overheidsapp's die Google gebruiken.
Bijvoorbeeld OmgevingsAlert, waar de gemeente de  omgevings vergunningen
moet melden. Daar is OSM superieur aan Google omdat in OSM wel huisnummers
staan.  Dan weet je waar het echt is. Groet,  Hugo
Op 7 jul. 2014 14:52 schreef OpenStreetMap-Talk-nl 
openstreetmap-talk...@basdelange.com:

 Jammer dat Google Maps wordt gebruikt:
 http://www.nu.nl/tech/3821287/app-toont-voedselveiligheid-
 nederlandse-lunchrooms.html
 http://www.inspectieresultaten.vwa.nl/iframe/inspectieresultaten.html

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

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

Re: [OSM-talk-nl] BAG gegevens Re: OSM Navigatieapparatuur

[Hugo Hölscher]

Maarten et.al.

Mee eens. Was in januari een topic op de nieuwjaarsborrel. Daarna stil. Hugo
Op 29 mei 2013 09:23 schreef Maarten Deen md...@xs4all.nl het volgende:

 On 2013-05-29 09:11, Minko wrote:

  Wb adresnavigatie, zowel Lambertus' osm kaarten als mijn Openfietsmap
 zijn voorzien van alle BAG adressen.


 Ik was de BAG alweer helemaal vergeten, maar het lijkt me leuk om daar wat
 meer van te gaan importeren.
 De wikipagina's 
 http://wiki.openstreetmap.org/**wiki/BAGhttp://wiki.openstreetmap.org/wiki/BAGen
 http://wiki.openstreetmap.org/**wiki/BAGimporthttp://wiki.openstreetmap.org/wiki/BAGimportzijn
  niet erg uitgebreid, bij wie moet ik aankloppen?

  Hierdoor is NL landelijk dekkend, al zijn er nog veel gevallen waar


 De gegevens moeten wel in OSM zitten willen andere kaartgebruikers er
 voordeel van hebben.

 Maarten

 __**_
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk-nl] junction= roundabaout

[Hugo Hölscher]

I do think there are situations were you want do a full roundabout.
Example: want toturn left on a road, but that is prohibited. Right is
allowed and there is a nearby roundabout. Then you will do a full-turn.
Hugo
Op 22 nov. 2012 10:03 schreef Maarten Deen md...@xs4all.nl het volgende:

 On 2012-11-22 09:41, Wolfgang Wienke wrote:

 Am 22.11.2012 07:50, schrieb Maarten Deen:

 On 2012-11-21 20:48, Wolfgang Wienke wrote:

 Am 21.11.2012 18:48, schrieb Maarten Deen:

 On 11/21/2012 06:45 PM, Maarten Deen wrote:

 On 11/21/2012 06:41 PM, Wolfgang Wienke wrote:
  Hi,
  I'm mapping in NL near Aachen. Can someone tell me, why there is
 more
  that ONE way in a dutch roundabaout?
 There isn't. A roundabout is always one way. If there are two
 directions
 it is not a roundabout but a circular road.

  Just after sending this I realized that I must have misread your
 question. You mean why most roundabouts are made up of more than one
 way.

 Initially it is because of the AND import. The AND dataset was such
 that
 between every junction of 3 or more roads there was a sperate way.

 What means the AND dataset?


 AND donated their dataset in 2007 and was subsequently integraded into
 OSM.
 http://wiki.openstreetmap.**org/wiki/AND_Datahttp://wiki.openstreetmap.org/wiki/AND_Data
 

 I do not find there any special about roundabouts. I think, that it
 is important to recognize a roundabout for navys to tell the user
 something like leave the rounabout at the second street.
 Is there no discussion in Netherlands to join the automatically
 generated part of a roundabout manually?


 No, because that is not necessary.
 The AND data was structured such that at every point where there is a
 juntion of three or more ways, a new way was created. You'll still see that
 in lots of parts of the Netherlands:
 http://www.openstreetmap.org/**?lat=51.319581lon=5.996067**
 zoom=18layers=Mhttp://www.openstreetmap.org/?lat=51.319581lon=5.996067zoom=18layers=M
 

 It is not necessary that the road Lindanusstraat is split up in 5 parts,
 but that is how the AND dataset came. You'll notice the AND_nosr_r tags on
 these ways, so you can see it came from AND that way. The same with
 roundabouts. Because every connecting road is a point where 3 ways connect,
 it was a different way.

 Routing engines have no adverse effects from this. There is no
 (sell-respecting) routing engine that will tell you to continue for 100
 metres a thousand times when the road is spilt up in smaller ways. So why
 would it do that on a roundabout?
 A roundabout is recognized by its tag: junction=roundabout. Not by its
 physical properties (a circular one-way street).

  Now it is just convenient if you have different relations (like a bus
 line) over the roundabout. Then you can indicate exactly which side a
 relation takes.

 Well, this is really not necessary because you drive the roundabout
 alwas in the same direction.
 In Germany we only have roundabouts made of ONE way. If you use the
 relation-editor of JOSM, than you can easily recgnize a roundabout.
 Would it not be easier, to use only ONE way in a roundabaout?


 I think this looks much tidier than when roundabouts are always one way.


 http://www.openstreetmap.org/**?lat=51.32506lon=5.97571**
 zoom=17layers=Thttp://www.openstreetmap.org/?lat=51.32506lon=5.97571zoom=17layers=T
 

 Also, if you make a route over a roundabout, you never use the full
 roundabout, so why would you want the full roundabout in the relation?


 Of course this is true, but I think it looks tidier the other way,
 look here. You see at once, that there is a roundabout.

 http://www.openstreetmap.org/?**lat=50.791022lon=6.059449**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=50.791022lon=6.059449zoom=18layers=T


 I don't see the difference there because it has only single ways
 connecting to the roundabout.

 But let me ask this simple question: if you go from A to B via a
 roundabout, do you traverse the whole roundabout or only a part of it? Why
 then add the full roundabout to a relation that describes the route from A
 to B?

 It is also clearer not to add the full roundabout. Take this example: 
 http://www.openstreetmap.org/**?lat=51.333905lon=5.995042**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=51.333905lon=5.995042zoom=18layers=T
 

 It is immediately clear that bus 62 goes from east to west. If you had the
 complete roundabout in the relation, the whole roundabout would be red and
 you would not know which direction the relation had.

 Regards,
 Maarten


 __**_
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk-nl] junction= roundabaout

[Hugo Hölscher]

Agree more the exeption then the rule. But any action which prohibits
routing for this situation should be avoided,
Hugo
Op 22 nov. 2012 12:48 schreef Jo winfi...@gmail.com het volgende:

 In that case you add all the ways of the roundabout to your route
 relation. You'll have to admit it's rather the exception than the rule.

 Jo


 2012/11/22 Hugo Hölscher hugoholsc...@gmail.com

 I do think there are situations were you want do a full roundabout.
 Example: want toturn left on a road, but that is prohibited. Right is
 allowed and there is a nearby roundabout. Then you will do a full-turn.
 Hugo
 Op 22 nov. 2012 10:03 schreef Maarten Deen md...@xs4all.nl het
 volgende:

 On 2012-11-22 09:41, Wolfgang Wienke wrote:

 Am 22.11.2012 07:50, schrieb Maarten Deen:

 On 2012-11-21 20:48, Wolfgang Wienke wrote:

 Am 21.11.2012 18:48, schrieb Maarten Deen:

 On 11/21/2012 06:45 PM, Maarten Deen wrote:

 On 11/21/2012 06:41 PM, Wolfgang Wienke wrote:
  Hi,
  I'm mapping in NL near Aachen. Can someone tell me, why there is
 more
  that ONE way in a dutch roundabaout?
 There isn't. A roundabout is always one way. If there are two
 directions
 it is not a roundabout but a circular road.

  Just after sending this I realized that I must have misread your
 question. You mean why most roundabouts are made up of more than one
 way.

 Initially it is because of the AND import. The AND dataset was such
 that
 between every junction of 3 or more roads there was a sperate way.

 What means the AND dataset?


 AND donated their dataset in 2007 and was subsequently integraded into
 OSM.
 http://wiki.openstreetmap.**org/wiki/AND_Datahttp://wiki.openstreetmap.org/wiki/AND_Data
 

 I do not find there any special about roundabouts. I think, that it
 is important to recognize a roundabout for navys to tell the user
 something like leave the rounabout at the second street.
 Is there no discussion in Netherlands to join the automatically
 generated part of a roundabout manually?


 No, because that is not necessary.
 The AND data was structured such that at every point where there is a
 juntion of three or more ways, a new way was created. You'll still see that
 in lots of parts of the Netherlands:
 http://www.openstreetmap.org/**?lat=51.319581lon=5.996067**
 zoom=18layers=Mhttp://www.openstreetmap.org/?lat=51.319581lon=5.996067zoom=18layers=M
 

 It is not necessary that the road Lindanusstraat is split up in 5
 parts, but that is how the AND dataset came. You'll notice the AND_nosr_r
 tags on these ways, so you can see it came from AND that way. The same with
 roundabouts. Because every connecting road is a point where 3 ways connect,
 it was a different way.

 Routing engines have no adverse effects from this. There is no
 (sell-respecting) routing engine that will tell you to continue for 100
 metres a thousand times when the road is spilt up in smaller ways. So why
 would it do that on a roundabout?
 A roundabout is recognized by its tag: junction=roundabout. Not by its
 physical properties (a circular one-way street).

  Now it is just convenient if you have different relations (like a bus
 line) over the roundabout. Then you can indicate exactly which side a
 relation takes.

 Well, this is really not necessary because you drive the roundabout
 alwas in the same direction.
 In Germany we only have roundabouts made of ONE way. If you use the
 relation-editor of JOSM, than you can easily recgnize a roundabout.
 Would it not be easier, to use only ONE way in a roundabaout?


 I think this looks much tidier than when roundabouts are always one
 way.


 http://www.openstreetmap.org/**?lat=51.32506lon=5.97571**
 zoom=17layers=Thttp://www.openstreetmap.org/?lat=51.32506lon=5.97571zoom=17layers=T
 

 Also, if you make a route over a roundabout, you never use the full
 roundabout, so why would you want the full roundabout in the relation?


 Of course this is true, but I think it looks tidier the other way,
 look here. You see at once, that there is a roundabout.

 http://www.openstreetmap.org/?**lat=50.791022lon=6.059449**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=50.791022lon=6.059449zoom=18layers=T


 I don't see the difference there because it has only single ways
 connecting to the roundabout.

 But let me ask this simple question: if you go from A to B via a
 roundabout, do you traverse the whole roundabout or only a part of it? Why
 then add the full roundabout to a relation that describes the route from A
 to B?

 It is also clearer not to add the full roundabout. Take this example: 
 http://www.openstreetmap.org/**?lat=51.333905lon=5.995042**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=51.333905lon=5.995042zoom=18layers=T
 

 It is immediately clear that bus 62 goes from east to west. If you had
 the complete roundabout in the relation, the whole roundabout would be red
 and you would not know which direction the relation had.

 Regards,
 Maarten


 __**_
 Talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Hugo Hölscher]

Lijkt me de goede benadering.  Hugo
Op 21 okt. 2012 11:07 schreef Gertjan Idema g.id...@zonnet.nl het
volgende:

 **
 On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:

 Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in de
 BAG viewer zie), data bevat die nog niet bestaan. Als je deze id zoekt:
 039710014064, vind je een huis en adres  in Heemstede waarvan de bouw
 nog niet eens begonnen is. Verder weet ik dat de bouw vergunning aan
 verandering onderhevig is. Gaan we met bulk up-loads nu de mogelijk
 toekomstige kaart van Nederland maken of is het wijsheid om de locaties
 waarvan de status is: “bouwvergunning verleend” er nog uit laten?



  Hugo


 Mijn insteek op dit moment is om gebouwen met status  Bouw gestart te
 taggen als building=construction. Voor Bouwvergunning verleend kan je
 overwegen om dat ook te doen, om wat meer informatie te geven aan een
 mapper die ziet dat er wat gaande is op een stukje grond. Daarnaast voeg ik
 een tag bag:status toe.

 Gertjan



  *From:* Gertjan Idema g.id...@zonnet.nl

  *Sent:* Saturday, October 20, 2012 8:54 PM

  *To:* talk-nl@openstreetmap.org

  *Subject:* Re: [OSM-talk-nl] Het taggen van BAG data.



  On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:

 Beste Gertjan e.a,
 Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week ververst 
 met versie 8 sept en 8 okt:

  Fijn dat je meedenkt :-)

 http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
  (Atom).e.e.a. moet ook simpeler worden in de 
 toekomst:http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
 Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.

 On 17-10-12 13:11, Gertjan Idema wrote: Er is een aantal initiatieven gaande 
 voor het opnemen van BAG data in Openstreetmap. - ruudblank heeft veel werk 
 verricht in Gorinchem. - rullzer in de omgeving Purmerend - mijn eigen 
 initiatief op basis waarvan Minko (Amersfoort), PeeWee (Leusden) en 
 Sebastiaan (Oldambt) nu  kleinschaligaan het testen zijn. - en 
 ongetwijfeld nog meer. Helaas is er nog geen standaard voor het taggen van 
 BAG data. Mijn idee van deze discussie is om hier samen te vatten wat er tot 
 nu toe gedaan en besproken is over het taggen van data afkomstig uit de 
 BAG. Vervolgens hoop ik dat we het samen eens kunnen worden over een 
 standaard. Deze kan dan opgenomen worden op de Wiki pagina en geïntegreerd 
 in tools en scripts. Het doel hierbij is niet om zoveel mogelijk BAG dat in 
 openstreetmap te krijgen, maar om te zorgen dat dit consistent gebeurt. 
 Eerst maar eens een inventarisatie: Adres tags op pand of losse nodes 
 = De BAG maakt onderscheid tussen panden, 
 verblijfsobjecten en nummeraanduidingen. Een pand kan meerdere 
 verblijfsobjecten bevatten.Ja het meestvoorkomende, maar ook omgekeerd 
 (meerdere Panden bij VBO), maar moet daarvan nog voorbeeld zien.

  Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
 Utrecht) ik heb ook nog even geen
 idee hoe we dit het beste in OSM zouden kunnen mappen.
 Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A). Hier
 zijn 2 panden samengevoegd en vervolgens opgedeeld in 7 verblijfsobjecten.
 Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten met
 2 panden per VBO.

  Tot nu toe heb ik de adressen als volgt getagd: Voor panden met een enkel 
  verblijfsobject heb ik de adres tags (addr:housenumber, addr:postcode, 
  addr:street) aan het pand gekoppeld met in tag ref:bagid het BAG id van 
  het pand. Voor panden met meerdere verblijfsobjecten heb ik aan het pand 
  geen adres tags gekoppeld, dit kunnen immers verschillende straten zijn. 
  De adres tags heb ik aan losse nodes gekoppeld met in tag ref:bagid het 
  BAG id van de nummeraanduiding. ruudblank heeft er in Gorinchem voor 
  gekozen om alle adressen los te koppelen van het pand. Als BAG referentie 
  gebruikt hij het BAG id van het verblijfsobject in de tag bag:vbo_id en 
  op de panden het BAG id van het pand in bag:pand_id. rullzer maakt 
  hetzelfde onderscheid als ik tussen panden met 1 of met meer 
  verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.Een lastige, 
  ik zou in ieder geval zo dicht mogelijk bij het BAG model blijven...Bijv. 
  kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes zijn (plm 9 
  miljoen in NL!)? En gekoppeld via relaties aan Panden ? In het achterhoofd 
  ook het soort gebruik van OSM adressen: Geocoders, Door-to-door navigation. 
  En verder aansluiten bij algemene OSM-conventies voor adressen.

  Relaties tussen panden en verblijfsobjecten/adressen worden voor zover
 ik weet niet gebruikt in OSM. En gezien het feit dat associatedStreet
 relaties amper gebruikt worden vanwege de complexiteit, denk ik dat een
 eventuele associatedBuilding relatie het niet gaat redden.
 Voor de meeste toepassingen zal een relatie tussen pand en adres niet echt
 belangrijk zijn, hoewel Cartinus