[OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Allroads]

Aanvullend:

In de BAG registratie staan ook OpenbareRuimte, die niet gebruikt worden voor 
een adres.

type kunstwerk, bruggen staan er meermaals in, dit is dan een verplicht item in 
de BGT , OpenbareRuimte_label.

Voorbeeld Leeuwenbrug geen adres aanwezig
type kunstwerk

https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=Leeuwenbrug=0=017130001066=179783.148=524782.59=4=017130001066

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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Allroads]

https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29

if the name can be spelled without an abbreviation, then don't abbreviate it. 

Houden aan wat wereldwijd gebruikelijk is. OSM methodiek.
Het is niet voor niets,  dat deze keuze is gemaakt, wereldwijd bruikbaarder 
maken, o.a bij het zoeken

m.a.w 
We hebben een OSM naam nodig, zonder abbreviation, zonder afkortingen, name=*
We hebben een officiele naam nodig, dat is de BAG naam inclusief afkortingen 
official_name=*. Dit zou zonder kunnen als de OSM naam en de BAG naam niet 
verschillen, maar toch misschien wenselijk om beide te vermelden.
We hebben een naam nodig, die we op de bordjes in de straat zien staan. OSM 
survey/ mapillary. Wanneer deze verschillen van de OSM naam en/of de BAG naam. 
We zien wel eens aparte schrijfwijzes, niet conform de naamsbesluit, hiervoor 
zou een key loc_name=* of alt_name=*  of anders, gebruikt kunnen worden. 
(discussie) (Als Nominatim het gebruikt is het nog beter).

Het adres bestaat uit een woonplaats, OpenbareRuimte en nummer.

De OpenbareRuimte heeft een ID nummer.
Dit nummer toevoegen aan de weg, weg is een type Openbare Ruimte.  Hiervoor 
zouden we een nieuwe key kunnen gebruiken alleen voor Nederland NL_OR_ID of zo. 
Dit kunnen we gezamenlijk besluiten, Nederlands ID.

Zo zijn er meerdere type Openbare Ruimte.
weg  water spoorweg kunstwerk terrein landelijk gebied administratief gebied.

Voorbeeld type water, Bovenwijde
https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?geometry.x=203308.5428125=526004.15984375=7=170810032943=170801023938

Voorbeeld type landelijk gebied, Vliehors
https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?geometry.x=123755.1025=583248.75875=4=009610382731=009601385021

Bepaalde place=* Tag kunnen dan ook een NL_OR_ID krijgen.
https://wiki.openstreetmap.org/wiki/Key:place

Dan hebben we gelijk de koppeling met andere type OpenbareRuimte gemaakt.

De basis: De Gemeenten zijn bepalend bij, per naamgevingsbesluit om een 
OpenbareRuimte te benoemen. Ik meen, dat zij nu, het enige lichaam is die 
Openbare Ruimtes mogen benoemen.
Wet BAG bepaald, hoe een adres moet worden geregistreerd, er zijn dus ook 
OpenbareRuimte, die wel benoemd zijn door Gemeentes, maar niet in der BAG 
komen. OpenbareRuimte is niet een onderdeel van het adres.
Wet BGT: bepaald dat wanneer een OpenbareRuimte is opgenomen in de BAG, dat 
deze als OpenbareRuimte_label moet worden opgenomen in de BGT (verplicht), BGT 
OpenbareRuimte (vlak) (niet verplicht).


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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[St Niklaas]

Hi,

Kunnen we in dit verlengde dan niet gelijk besluiten om de verwijzingen mbt 
data die een mindere graad van betrouwbaarheid kennen dan OSM  voor gebruik in 
of voor OSM uit te sluiten ? Met de uitzondering van Mapillaria daar dat 
uiteindelijk slechts een weergave van de werkelijkheid betreft.

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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Richard Duivenvoorde]

On 4/14/20 7:48 PM, Colin Smale wrote:
> On 2020-04-14 18:52, g.id...@zonnet.nl wrote:

>> Voor de straten is er de optie om de tag alt_name te gebruiken voor de
>> BAG naam, als deze afwijkt van de uitgeschreven naam. Dit zie je
>> bijvoorbeeld in Bunnik en Odijk. Dan zijn echter de namen op de
>> straten en niet op de adressen. Een tag voor de officiele straatnaam
>> op een adress heb ik niet kunnen vinden. Dat zou iets als
>> addr:street:official of zo moeten worden.
>  
> Dit gaat niet echt over straatnamen, maar over de schrijfwijze ervan. Er
> is maar één bron van de officiële volledige schrijfwijze: het
> gemeentebesluit waarin de naam wordt toegekend. Daarnaast zijn er
> verschillende erkende schrijfwijzen in gebruik, met eigen regels voor
> afkortingen, leestekens, accenten, hoofdletters, numerieke delen, enz.
>  
> https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/basisregistraties-en-afsprakenstelsels/stelsel-van-basisregistraties/schrijfwijze-registreren-en-presenteren-adressen-stelsel-basisregistraties/
>  
> De straatnaam zoals die in de BAG staat, is misschien niet helemaal
> gelijk aan het gemeentebesluit - en dan heb je altijd de mogelijkheid
> van een typefout.
>  
> Of een straatnaam (bijvoorbeeld) met puntjes of zonder geschreven wordt,
> verandert niets aan de eigenlijke straatnaam; een mens ziet misschien
> makkelijker dan een computer dat het om dezelfde straat gaat.

In dit geval denk ik dat we in Nederland nu hebben besloten om BAG de
officiele basisregistratie te laten zijn?
En als ik naar bijvoorbeeld mijn straat kijk:

https://bag.basisregistraties.overheid.nl/bag/doc/openbare-ruimte/039230011160

Dan zie ik zelfs een verwijzing naar een "brondocument". Ik zou er
eigenlijk voor pleiten om in Nederland de BAG schrijfwijzen te hanteren
voor alle adressen en straten. Dat maakt data-koppelingen (op
straatnaam/adres) zo veel makkelijker.

Ik zag dat er (veel?) discussie is geweest om ook wikidata id's toe te
voegen:

https://lists.openstreetmap.org/pipermail/talk/2020-March/084260.html

Dus in mijn ogen zou het toevoegen van de BAG id's aan de adressen
(==verblijfobjecten toch?) verschillende voordelen hebben:
- koppelbaarheid van de OSM-adressen aan andere overheidsgerelateerde data
- mogelijkheid om BAG-updates te monitoren (hoewel ik begrijp dat hoewel
er staat 'source:BAG' men toch (straatnaam) aanpassingen maakt?)

In deze tijd waarin ook de overheid steeds meer into 'linked'-data is,
wordt het natuurlijk interessant om zelf ook 'linkable' te zijn?

Wordt het WFS-script nog wel eens gerund? En zou het dan mogelijk zijn
om de BAG-id's toe te voegen?
Of alleen voor beperkte delen van NL?

Groet,

Richard Duivenvoorde






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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Just van den Broecke]

On 14-04-20 18:52, g.id...@zonnet.nl wrote:

Hoi Gerard,


Hoi Richard,



.
.
Nu er een prijskaartje aan de BAG hangt, is de drempel voor dat soort 
hobby projectjes toch wat hoger.


Ben even benieuwd: refereer je hier aan feit dat BAG Extract v2 mogelijk 
niet meer gratis via PDOK beschikbaar wordt, en bij Kadaster moet 
aangekocht? Dat zijn plannen, zal m.i. zo'n vaart niet lopen. Anders 
kopen we gezamelijk in.


Of refereer je aan https://geotoko.nl? Waar de met NLExtract-verwerkte 
BAG (PG, CSV) inderdaad verstrekkingskosten kent. Ik heb het misschien 
niet helemaal duidelijk gecommuniceerd, maar voor projecten als OSM kan 
deze data gratis afgenomen. Heb al aantal gratis  of om bijna niets 
verstrekt. Maar denk dat meesten van jullie gewoon NLExtract draaien.


Zelfde geldt voor https://map5.nl ondergrondkaarten als OpenTopo (PDOK 
heeft alleen RD tiling). Aantal mappers maken ook gebruik van korting 
tot gratis.


Groeten,

Just



Groeten, Gertjan



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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[g . idema]

On 14-04-2020 19:48, Colin Smale wrote:

Als je op GitHub kijkt, zijn de extracten (gratis) per gemeente te 
downloaden. Heb je daar wat aan?

https://github.com/lvbag/BAG-2.0-Extract/tree/master/BAG%202.0%20gemeente%20extracten%20productie

Interessent. Ik ga hier zeker eens naar kijken. Wel jammer dat die 14 
grootste gemeenten apart gedownload moeten worden.



___
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 straatnamen (ook?) in OSM

[Colin Smale]

On 2020-04-14 18:52, g.id...@zonnet.nl wrote:

> Hoi Richard,
> 
> De adressen in OSM worden bijgewerkt op basis van de BAG WFS. Daarin staan 
> echter geen BAG adres id's, maar BAG verblijfsobject id's. Dat is de reden 
> dat geen BAG id's op de adressen in OSM zitten. Wat ik zelf overigen ook een 
> groot gemis vind.
> Op de panden zitten wel BAG id's. Op de straten weer niet.
> 
> Voor de straten is er de optie om de tag alt_name te gebruiken voor de BAG 
> naam, als deze afwijkt van de uitgeschreven naam. Dit zie je bijvoorbeeld in 
> Bunnik en Odijk. Dan zijn echter de namen op de straten en niet op de 
> adressen. Een tag voor de officiele straatnaam op een adress heb ik niet 
> kunnen vinden. Dat zou iets als addr:street:official of zo moeten worden.

Dit gaat niet echt over straatnamen, maar over de schrijfwijze ervan. Er
is maar één bron van de officiële volledige schrijfwijze: het
gemeentebesluit waarin de naam wordt toegekend. Daarnaast zijn er
verschillende erkende schrijfwijzen in gebruik, met eigen regels voor
afkortingen, leestekens, accenten, hoofdletters, numerieke delen, enz. 

https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/basisregistraties-en-afsprakenstelsels/stelsel-van-basisregistraties/schrijfwijze-registreren-en-presenteren-adressen-stelsel-basisregistraties/


De straatnaam zoals die in de BAG staat, is misschien niet helemaal
gelijk aan het gemeentebesluit - en dan heb je altijd de mogelijkheid
van een typefout. 

Of een straatnaam (bijvoorbeeld) met puntjes of zonder geschreven wordt,
verandert niets aan de eigenlijke straatnaam; een mens ziet misschien
makkelijker dan een computer dat het om dezelfde straat gaat. 

> Ik kan op dit moment eenvoudige oplossing bedenken. Dan kom je toch geo 
> oplossingen zoals die van Bas, of koppelingen op basis van 
> postcode-huisnummer. In het verleden (2015) heb ik wel eens een vergelijking 
> gemaakt tussen OSM en BAG straten (zie bijlage). Misschien heb je daar iets 
> aan.
> 
> Nu er een prijskaartje aan de BAG hangt, is de drempel voor dat soort hobby 
> projectjes toch wat hoger.

Als je op GitHub kijkt, zijn de extracten (gratis) per gemeente te
downloaden. Heb je daar wat aan? 
https://github.com/lvbag/BAG-2.0-Extract/tree/master/BAG%202.0%20gemeente%20extracten%20productie___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Sebastiaan Couwenberg]

On 4/14/20 5:08 PM, Richard Duivenvoorde wrote:
> Is er dan een andere mogelijkheid om, gegeven een officieel adres of
> straatnaam, een koppeling te maken met een OSM straat of pand?

Op basis van de coordinaten in de BAG kan de node of way met dat adres
in OSM gevonden worden, en op basis daarvan kan de dichtsbijzijnde
straat met die naam gevonden bijvoorbeeld met een algoritme zoals
geimplementeerd in de FixAddresses plugin:

 https://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses

De meeste mappers zijn actief op het forum, daar zal je vraag meer
mensen berijken:

 https://forum.openstreetmap.org/viewforum.php?id=12

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Richard Duivenvoorde]

Hoi,

Iemand probeert hier nederlandse BAG adressen te koppelen aan
OpenStreetMap straatnamen. Nu wil het geval dat de OSM straatnamen in de
adressen niet (altijd) overeenkomen met de BAG.

Even googlen geeft mij:

https://wiki.openstreetmap.org/wiki/NL:BAGimport_via_ODS_plugin#STAP_4_Nabewerking

Waarin expliciet staat dat het een OSM conventie is om straatnamen UIT
te schrijven. Dus waarschijnlijk krijg ik problemen wanneer ik de
straatnamen BAG conform zou aanpassen :-)

Is er dan een andere mogelijkheid om, gegeven een officieel adres of
straatnaam, een koppeling te maken met een OSM straat of pand?
Ik dacht dat er misschien wel BAG-id's in de data zouden zitten, maar ik
zie ze niet in de verschillende editors die ik online kon bekijken.

Een andere optie zou natuurlijk zijn om een 'way' een alternatieve naam
te geven (net zoals plaatsnamen alternatieve namen hebben)? Een
'bag-spelling' ofzo?

Iemand hier een idee over. Of kan iemand me wijzen waar hier eerder over
gesproken is?

Vriendelijke Groet,

Richard Duivenvoorde

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

Re: [OSM-talk-nl] BAG-plugin

[Johan C]

Hoi Ronald

Hij is zeker nog niet af, wat komt doordat het nog best ingewikkeld is om
de BAG en OSM met elkaar te vergelijken. Daar komt bijvoorbeeld nog bij dat
er sinds een week een probleem is met importeren vanuit de BAG WFS.

Wordt vervolgd...

Johan
Op 4 jun. 2016 08:42 schreef "Ronald Stroethoff" :

> Enige maanden geleden waren er meldingen over een nieuwe versie van de BAG-
> plugin.
> Toen werd er gemeld dat hij klaar was maar dat hij door een selecte groep
> in
> de praktijk getest moest worden.
> We zijn nu enige maanden verder en ik ben benieuwt wat de status daarvan
> is.
> Kan iemand mij daarover wat meer vertellen?
>
> Ronald
>
>
> ___
> 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

[OSM-talk-nl] BAG-plugin

[Ronald Stroethoff]

Enige maanden geleden waren er meldingen over een nieuwe versie van de BAG-
plugin.
Toen werd er gemeld dat hij klaar was maar dat hij door een selecte groep in 
de praktijk getest moest worden.
We zijn nu enige maanden verder en ik ben benieuwt wat de status daarvan is.
Kan iemand mij daarover wat meer vertellen?

Ronald


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

Re: [OSM-talk-nl] BAG update

[Sebastiaan Couwenberg]

On 08-01-16 15:01, Éric Piel wrote:
> Are there any recommended ways to update the BAG imported building data?
> I had a look at these pages in the wiki, but they appear to not have
> been updated for a while:
> http://wiki.openstreetmap.org/wiki/BAGimport
> http://wiki.openstreetmap.org/wiki/BAGimport_via_ODS_plugin
> 
> I'm fairly experienced with JOSM, and I have done some building imports
> previously.
> 
> Thanks for any pointer or help!

The new version is JOSM plugin is not widely available yet, in the mean
time we coordinate BAG updates on the forum:

http://forum.openstreetmap.org/viewtopic.php?id=52973

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[OSM-talk-nl] BAG update

[Éric Piel]

Hi,

Around my place (Delft) there are various places where the buildings are 
not up-to-date anymore. It's easy to remove destroyed buildings, but 
quite more work to draw new ones. The BAG is up-to-date (even a bit 
ahead sometimes).


Are there any recommended ways to update the BAG imported building data? 
I had a look at these pages in the wiki, but they appear to not have 
been updated for a while:

http://wiki.openstreetmap.org/wiki/BAGimport
http://wiki.openstreetmap.org/wiki/BAGimport_via_ODS_plugin

I'm fairly experienced with JOSM, and I have done some building imports 
previously.


Thanks for any pointer or help!
Éric

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

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Just van den Broecke]

Hoi Elmer,

Graag dit soort meldingen naar alleen de NLExtract lijst. Dit is dan de 
laatste cross-post...sorry mensen.


In de laatste (GitHub) versie van NLExtract is rekening gehouden met 
MultiPolygonen, zie issue 
https://github.com/opengeogroep/NLExtract/issues/138.


Deze worden in de juni-2015-versie van BRT in ieder geval ook door 
Kadaster geleverd en door NLExtract goed ingelezen. In jouw geval lijkt 
er egens een mismatch tussen jouw NLExtract versie, je database en de 
BRT brondata.


De dump van bijv juni 2015 
http://data.nlextract.nl/top10nl/postgis/jun2015/ bevat deze 
MultiPolygonen.


Groet,

Just

On 28-07-15 16:35, Elmer Cladder - Geodan wrote:

Ha Just,

Ik liep tijdens het inlezen van BRT april 2015 na het splitten tegen het
volgende aan:

Warning 1: Geometry to be inserted is of type Multi Polygon, whereas
the layer geometry type is Polygon.
Insertion is likely to fail
ERROR 1: INSERT command for new feature failed.
ERROR:  Geometry type (MultiPolygon) does not match column type
(Polygon)
Command: INSERT INTO functioneelgebied_vlak (wkb_geometry ,
fid, identificatie, objectbegintijd, versiebegintijd,
typefunctioneelgebied,
  brontype, bronbeschrijving, bronactualiteit,
bronnauwkeurigheid, dimensie, visualisatiecode, tdncode)
VALUES ('010620407102

00010300010029003BDF4F8DACEF0E415A643BDFD2ED2141DD2406811CEE0E4152B81E05D1ED214125068195E7ED0E4191ED7CFFC2ED2141FED478E9A4ED0E4191ED7CFFC2

ED21414A0C022B73ED0E413F355E3AD0ED2141643BDF4FB4E90E41BA490C42CCED21417FE90E410080BEED214185EB51B83CE90E41FA7E6A3CBEED2141A01A2FDD08E90E41

AE47E1BACBED21416ABC749378E50E419EEFA706C8ED214185EB51B844E50E416891EDBCB9ED21415EBA490C02E50E41F4FDD478B9ED2141A245B6F3C9E40E411D5A643BC7ED2141378941

6030E30E419AD9C4ED21416DE7FBA9C8E20E41E5D0225BB7ED2141B29DEFA7DAE20E41BC7493D8CFEC2141B07268910FE30E410AD7A3F0C3EC2141273108AC35E30E41F2D24DE2B9EC

2141FA7E6ABC1CE70E417D3F351EBEEC2141E17A14AE1BE70E41C1CAA1C5AEEC2141CFF753E355E70E41B0726811ABEC2141F853E3A563E70E41A245B6F3A8EC21418716D9CE8AE70E4106

819503A1EC2141C976BE9F99E70E41D34D629076EB21410C022B87DEE80E41E7FBA9F178EB21410C022B87DEE80E410E2DB25D65EB214125068195E9EC0E412B87169969EB214148E17A14

29ED0E41E7FBA9F178EB2141DD2406811EED0E41643BDF4FDAEB2141295C8FC2ECEC0E41A4703D8AE7EB214125068195E9EC0E416891EDBCF8EB2141F6285C8F1FED0E418716D90E03EC21

41EE7C3F3519ED0E41295C8F826AEC21411D5A643BE3EC0E41D578E92676EC2141DFEC0E411F85EBD186EC2141D122DBF914ED0E4152B81E8593EC2141E17A14AE0FED0E4191ED

7CFFC4EC21418195438BBEEF0E412731082CC8EC2141D9CEF75315F00E4177BE9F9ADDEC2141A8C64B3701F00E41FA7E6A3CBEED21413BDF4F8DACEF0E415A643BDFD2ED2141010300

010005000E2DB29DA1EC0E41508D97EE14EB2141F2D24D629DEC0E410E2DB29D45EB21415EBA490C75EB0E410C022B0744EB21416210583978EB0E41C3F5289C13EB21410E2DB2
9DA1EC0E41508D97EE14EB2141'::GEOMETRY, 100010856,
'NL.TOP10NL.100010856', '2008-11-24T00:00:00.000',
'2015-03-28T20:25:53.000', 'gaswinning', 'luchtfo
to', 'Een orthogerectificeerde fotografische opname van een deel van
het aardoppervlak. Gemaakt vanuit een vliegtuig.', '2014-01-01',
0.1, '2D', 19130
, 999) RETURNING ogc_fid
ERROR 1: Terminating translation prematurely after failed
translation of layer FunctioneelGebied_Vlak (use -skipfailures to
skip errors)


Heb jij dit ook gehad en zo ja, hoe heb je dit opgelost?

Groet, Elmer

On Sunday, April 26, 2015 at 11:56:13 PM UTC+2, Just van den Broecke wrote:

Sorry voor cross-posting.

Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
Top10NL via PDOK beschikbaar gekomen.

NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
beschikbaar gesteld:

Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
BAG: http://data.nlextract.nl/bag (ook CSV)

Hartelijke groet,

--Just










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

Re: [OSM-talk-nl] BAG vs On-The-Ground

[Colin Smale]

 

Ik heb een reactie ontvangen van Gemeente Woerden. De schrijfwijze in
het raadsbesluit is met een kleine letter voor het tweede deel. Dus het
raadsbesluit en de BAG komen overeen. De straatnaamborden zijn dus
verkeerd en de gemeente zegt dat de schrijfwijze verbeterd wordt bij
vervanging van de borden. 

De uitzondering bevestigt de regel... Deze schrijfwijze wijkt af van de
rest van Nederland, maar is toch juridisch juist. 

Voor de duidelijkheid heb ik een note=* aan deze straten toegevoegd. 

//colin 

On 2015-05-31 20:07, Johan C wrote: 

 Het beste blijft, lijkt me, contact opnemen met de gemeente en de verschillen 
 bij hen aangeven. Uiteraard heb je een punt dat niet alleen straatnaamborden 
 maar eventueel ook de BAG fout zou kunnen zijn (fout = afwijken van het 
 formele besluit). Mocht je met Gemeente Woerden contact opnemen, dan ben ik 
 benieuwd naar de uitkomst daarvan. 
 
 Cheers, Johan 
 
 Op 31 mei 2015 19:50 schreef Colin Smale colin.sm...@xs4all.nl:
 
 En als de BAG niet overeenkomt met het formele Straatnaambesluit, 
 bijvoorbeeld a.g.v. een typfout? Volgens mij prevaleert dan het Besluit en 
 moet de BAG worden bijgewerkt. Het is dus niet voldoende om alleen de BAG te 
 raadplegen - je moet het Straatnaambesluit bij de gemeente opvragen. 
 Misschien zijn de borden wel goed, en de BAG niet. 
 
 Het spreekt voor zich (IMHO) dat de straatnaam op de adres-nodes overeen moet 
 komen met de straatnaam op de weg waar het adres bij hoort. Als de naam op de 
 weg wordt aangepast omdat ik de OTG-regel toepas, hoe kan ik het verband 
 tussen de adres-nodes en de weg handhaven? We kunnen dit doen door ook de 
 adres-nodes aan te passen, maar dan is de bron van de naam niet langer de BAG 
 maar survey bijvoorbeeld. 
 
 //colin 
 
 On 2015-05-31 14:11, Johan C wrote: 
 1. OSM heeft ook het principe dat afkortingen voluit geschreven moeten worden 
 in tegenstelling tot naamgeving op borden 
 2. Op het forum zijn ook al eens gevallen langsgekomen waarbij de naam van 
 een straat op meerdere borden in die straat verschillend geschreven werd 
 3. Aangezien gemeenten zich behoren te houden aan de BAG zou de beste 
 oplossing zijn om gemeenten te wijzen op hun fout en hen de kans geven om 
 binnen een redelijke termijn de bebording te vervangen 
 
 Cheers, Johan 
 
 Op 31 mei 2015 12:37 schreef Sebastiaan Couwenberg sebas...@xs4all.nl:
 On 05/31/2015 12:14 PM, Colin Smale wrote:
 Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
 Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
 de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
 dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw
 ik in deze gevallen de borden als correcter dan de BAG. Degene die de
 BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
 straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
 niet langer met de borden en de conventies.
 
 Dus hebben we een situatie geschapen waarbij een officieel register
 zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
 overschrijden we één van de basisbeginselen van OSM.
 
 Wat vindt men hier zoal van?
 
 Het on-the-ground principe voor de extacte schrijfwijze van borden weegt
 wat mij betreft niet zo zwaar.
 
 De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk
 van voor de tijd dat dit een wettelijk plicht was. Of wijken hier van af
 ivm beperkte ruimte op de borden.
 
 Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima
 acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak
 en estetische waarde.
 
 Mvg,
 
 Bas
 
 --
 GPG Key ID: 4096R/6750F10AE88D4AF1
 Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
 
 ___
 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

___
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 en Top10NL PostGIS dumps van april 2015

[Ster, Eric van der (CIV)]

Wat wellicht ook kan helpen:

Publicatieplicht verkeersbesluiten:
http://www.vng.nl/onderwerpenindex/milieu-en-mobiliteit/wegenverkeerswet/brieven/elektronische-bekendmaking-verkeersbesluiten

https://zoek.officielebekendmakingen.nl/zoeken/resultaat/?zkt=Uitgebreidpst=Tractatenblad|Staatsblad|Staatscourant|Gemeenteblad|Provinciaalblad|Waterschapsblad|BladGemeenschappelijkeRegeling|ParlementaireDocumentenvrt=verkeersbesluitzkd=InDeGeheleTextdpr=Allespd=20150611epd=20150611sdt=DatumPublicatieap=pnr=1rpp=10


(loket met publicaties kan ik zo even niet zo snel vinden). Middels 
verkeersbesluiten kun je zien wat de wegbeheerder aan verkeersmaatregelen neemt.

RWS beheert het borden bestand met bewegwijzering. Wordt nog opengesteld voor 
hergebruik.

Eric van der Ster

Van: St Niklaas [mailto:st.nikl...@live.nl]
Verzonden: woensdag 10 juni 2015 17:23
Aan: OpenStreetMap NL discussion list
Onderwerp: Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

Beste Maarten Deen,

Onderstaand het mail adres van de vereniging van borden fabrikanten in 
Nederland.

i...@vnvf.nlmailto:i...@vnvf.nl

Ik ben benieuwd, mijn vorige poging om het digitale bordenboek voor OSM binnen 
te halen strandde op u kunt het kopen, zonder een afspraak aangaande de rechten 
van de plaatjes.

Hendrikklaas

Voor een bezichtiging kun je beter een fabrikant uit  de onderstaande lijst 
benaderen;

http://www.vnvf.nl/links/

succes


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

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Pander OpenTaal]

On 06/10/2015 01:03 AM, St Niklaas wrote:
 Hi Just,

Pander :)

  
 Probleem BAG meldingen gaan naar het kadaster, die zijn echter wel
 gemeentelijk georienteerd. Zonder gemeente naam of code  sturen ze een
 melding als onbestelbaar retour, niet vriendelijk maar uitzoeken is
 nachtwerk.
  
 Mvg
  
 Nick

Ik heb mijn script nu zeer generiek gemaakt en deze rapporteert nu voor
alle interessante kolommen in de BAG-export:
- TSV-bestand met histogram van waarden
- TSV-bestand histogram van gebruikte karakters
en het maakt een CSV-bestand met de desbetreffende regels waar een fout
in zit.

De fouten heb ik aan dit bericht toegevoegd. Het zijn fouten in 179
adressen die voorkomen uit maar 7 fouten in straatnamen. Wie kan dat
doorzetten?

De TSV-bestanden zijn interessant als je statistische gegevens over
Nederlandse adressen wil hebben en BAG-export op fouten wil controleren.
Hieronder staat voor een aantal bestanden de eerste en de laatste vijf
regels met korte toelichting:



Meeste adressen per provincie zijn in Zuid-Holland en de minste in
Flevoland:
histogram_values_provincie.tsv
1867916 Zuid-Holland
1479784 Noord-Holland
1218314 Noord-Brabant
1003293 Gelderland
614422  Utrecht
...
346361  Friesland
303551  Groningen
250258  Drenthe
221034  Zeeland
183197  Flevoland



Meeste en minste adressen betreft gemeentes zijn:
histogram_values_gemeente.tsv
473108  Amsterdam
352579  Rotterdam
281475  's-Gravenhage
164292  Utrecht
114006  Eindhoven
...
2700Haarlemmerliede en Spaarnwoude
2118Renswoude
1466Schiermonnikoog
1189Vlieland
671 Rozendaal



In de namen van gemeentes komen de volgende karakters veel en zeer
zelden voor:
histogram_chars_gemeente.tsv
654 e
317 n
276 r
248 a
202 l
...
2   .
2   '
1   ú
1   â
1   ,



Naast de gemeentes zijn er de woonplaatsen met aantal adressen:
histogram_values_woonplaats.tsv
473108  Amsterdam
318470  Rotterdam
281475  's-Gravenhage
145927  Utrecht
114006  Eindhoven
...
7   Ossenwaard
6   Breezanddijk
6   Idzega
5   Smallebrugge
5   Geelbroek



Ook deze hebben ongebruikelijke karakters:
histogram_chars_woonplaats.tsv
3597e
1615r
1590n
1198a
1190o
...
4   û
2   2
1   1
1   é
1   ú



Als je de Postcodestaatsloterijwhatever belangrijk vindt denk maar eens
na of dit invloed heeft op jouw leven en of je moet verhuizen:
histogram_values_postcode.tsv
11923781PP
837 3896LD
821 1083HP
811 4325DM
792 6598LA
...
1   2743CH
1   7957ED
1   8064XM
1   3371SP
1   5091JK



De meeste postcodes bevatten een '1' en zeer zelden een 'U':
histogram_chars_postcode.tsv
304752  1
229836  2
212903  3
195599  5
177934  4
...
23  O
18  Q
7   Y
4   F
1   U



Meeste adressen hebben geen huisnummertoevoeging, maar als er die is, is
het meestal een '1' of '2' en zeer zelden lange toevoegingen, al kunnen
die wel complex zijn:
histogram_values_huisnummertoevoeging.tsv
8062787 
58224   1
52691   2
41433   H
39908   3
...
1   R348
1   A87
1   3329
1   k03I
1   18b



De meeste huisnummers zijn een '1', daarna een '2' en ga maar door. De
meest zeldzame zijn vrij lang. Die mensen kun je post sturen zonder
woonplaats, postcode of straatnaam. Dat laatste zou je ook over zeldzame
huisnummertoevoegingen kunnen zeggen:
histogram_values_huisnummer.tsv
245526  1
229318  2
197155  3
196194  4
189590  5
1   5269
1   4090
1   16524
1   5841
1   23010



Ik weet niet exact wat dit is maar er zijn 26294 nevenadressen in Nederland:
histogram_values_nevenadres.tsv
8599746 f
26294   t



Weet iemand wat dit voor informatie is? VBO=? STA=staplaats? LIG=ligplaats?
histogram_values_object_type.tsv
8599234 VBO
14963   STA
11843   LIG



De gewone man woont in de Dorpsstraat. Zou er iemand wonen in
Metrostation Wibautstraat? Is er een boerderij op de Weelhoekweg?
histogram_values_openbareruimte.tsv
27335   Dorpsstraat
22191   Kerkstraat
17289   Hoofdstraat
15106   Molenstraat
14611   Schoolstraat
...
1   Waldfeuchterweg
1   Metrostation Wibautstraat
1   Hilweg
1   Herschelpad
1   Weelhoekweg



Straatnamen kunnen dus ook ongebruikelijke karakters bevatten:
histogram_chars_openbareruimte.tsv
232432  e
183629  a
136113  r
124896  t
110114  n
...
1   ,
1   î
1   Á
1   ñ
1   ř



Afijn, een hele berg data ter lering en vermaak. Stichting OpenTaal kan
aan de hand van deze statistieken beter beslissen welke namen, die we
via meerdere wegen bijgedragen gekregen hebben, op te nemen in de
Nederlandse spellingcontrole.

Wie is dé persoon die met de export van BAG regulier aan de slag gaat
voor OSM en andere open toepassingen? Graag zou ik mijn script willen
doneren die naast TSV en CSV ook kan rapporteren in HTML en XML. Op die
manier orden deze lijsten en statistische gegevens makkelijker ontsloten
aan iedereen die met adresinformatie te maken heeft.

Groeten,

Pander
-- 
Stichting 

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Sebastiaan Couwenberg]

 De fouten heb ik aan dit bericht toegevoegd. Het zijn fouten in 179
 adressen die voorkomen uit maar 7 fouten in straatnamen. Wie kan dat
 doorzetten?

Je bent zelf de meeste aangewezen persoon om deze fouten terug te melden.

https://www.kadaster.nl/web/formulier/BAG-formulieren/BAG-terugmeldingsformulier.htm

Lees ook het BAG processenhandboek waarin de verschillende velden
beschreven zijn, zo kan je duidelijk geformuleerde terugmeldingen doen.

http://www.kadaster.nl/web/artikel/download/BAG-processenhandboek-2013-1.htm

Mvg,

Bas


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

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Gert-Jan van der Weijden]

Leuk, die Dvořákhof (in Hoorn)!
En mooi dat de volledige naam er wordt gebruikt, en geen verminking waarbij het 
Tsjechisch haakje (haček) wordt weggelaten.
Strafpunten voor Zwijndrecht, dat botweg alle diakritische tekens in de naam 
van deze componist negeert.
Uit het feit dat de Dvorakstraat in Zwijndrecht bij de Mozartlaan in de buurt 
ligt concludeer ik maar even dat het daadwerkelijk om de componist Dvořák gaat, 
en niet om de Amerikaanse uitvinder van een toetenbordindeling August Dvorak. 
(2 aardige details: 200 m verderop in Zwijndrecht ligt een straat met de naam 
Kaartenmaker. En die Hoornse Dvořákhof heeft ook een eigenaardigheid: voor 
een deel is van de straat waarvan de ene zijde Dvořákhof heet, en de andere 
zijde Smetanahof. Wie verzint zoiets?)

Verder: ook de naam van de Tsjechoslowaakse voorman van de Praagse Lente Dubček 
op veel plaatsen ook verminkt tot Dubcek. En componist Béla Bartók komt op 
alle mogelijke manier voor in de Nederlandse straatnamen. Met alleen een accent 
op de e van Bela, met 2 accenten, geheel zonder accenten, en zelfs 
-ongetwijfeld goedbedoeld- met een accent de verkeerde kant uit.

Het geeft allemaal wel het belang aan van de flexibiliteit van geocoders en 
andere straatnaamzoekers. Het zou rottig zijn als de hulpdiensten de route naar 
de Dvořákhof niet weet te vinden omdat de brandweerman de r-met-haček niet op 
zijn navigatiesysteem kan intoetsen.


groet, 

Gert-Jan van der Weijden (met streepje, puntjes op de ij etc.)





-Oorspronkelijk bericht-
Van: Pander OpenTaal [mailto:pan...@opentaal.org] 
Verzonden: dinsdag 9 juni 2015 22:16
Aan: OpenStreetMap NL discussion list; du...@lists.osgeo.org; 
nlextr...@googlegroups.com; OpenGeoGroep Mailinglist
Onderwerp: Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

On 04/26/2015 11:56 PM, Just van den Broecke wrote:
 Sorry voor cross-posting.
 
 Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
 Top10NL via PDOK beschikbaar gekomen.
 
 NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
 beschikbaar gesteld:
 
 Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
 BAG: http://data.nlextract.nl/bag (ook CSV)

Ik heb wat analyses gedaan op de export van BAG in CSV en heb de
volgende fouten gevonden:

ERROR dubbele spatie in straatnaam Burg. v. Dobben de  Bruijnstraat
ERROR dubbele spatie in straatnaam Burgemeester  Groenenbergstraat
ERROR dubbele spatie in straatnaam Wethouder M J van den  Hatertstraat
ERROR dubbele spatie in straatnaam Provinciale  Weg
ERROR dubbele spatie in straatnaam Burgemeester  Wientjensstraat
ERROR dubbele spatie in straatnaam Oranje  Gelderlandlaan
ERROR back quote in straatnaam `t Hoge Heem

Kan iemand deze doorgeven aan de beheerder van BAG? Een van jullie zit
vast dichter bij het vuur.



De tien meest voorkomende straatnamen zijn:
Dorpsstraat
Kerkstraat
Hoofdstraat
Molenstraat
Schoolstraat
Nieuwstraat
Wilhelminastraat
Julianastraat
Hoofdweg
Stationsstraat

Ik zal eens kijken welke straatnamen in de aankomende spellingcontrole
nog op kunnen nemen

Aantal opmerkelijke straatnamen met karakters die nergens anders worden
gebruikt zijn:

Örehof
Önninkweg
Öldersweg
Salvador Dalístraat
Estelístraat
De Holtskòle
Bartòk
São Paulodreef
São Paulostraat
Ávilastraat
Nîmeslaan
Buñuellaan
Laan van Køge
Dvořákhof

Van deze laatste is naar mijn idee de ř een brug te ver. Over het
algemeen wordt een haček (behalve in het woord haček) in het Nederlands
weggelaten. Wat vinden jullie?

Groeten,

Pander

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


-- 
Stichting OpenTaal
http://opentaal.org
http://twitter.com/opentaal

___
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 en Top10NL PostGIS dumps van april 2015

[Colin Smale]

 

De straat heet hoe de straat heet - spelfouten inbegrepen. De bron van
de enige echte naamgeving is een gemeentelijk besluit. Dat wordt
(hopelijk zonder fouten) overgenomen in de BAG. Ik weet niet waar degene
kijkt die straatnaamborden bestelt, maar ook daar kan een foutje
insluipen. En vervolgens kan de bordjesfabrikant ook een fout maken.
Zeker als die gekke tekens niet makkelijk in te voeren zijn vanaf een
normaal toetsenbord. 

Het is dus zaak om te achterhalen waar in de keten de fout is ontstaan,
en het probleem op de juiste plek op te lossen. 

//colin 

On 2015-06-10 14:08, Gert-Jan van der Weijden wrote: 

 Leuk, die Dvořákhof (in Hoorn)!
 En mooi dat de volledige naam er wordt gebruikt, en geen verminking waarbij 
 het Tsjechisch haakje (haček) wordt weggelaten.
 Strafpunten voor Zwijndrecht, dat botweg alle diakritische tekens in de naam 
 van deze componist negeert.
 Uit het feit dat de Dvorakstraat in Zwijndrecht bij de Mozartlaan in de buurt 
 ligt concludeer ik maar even dat het daadwerkelijk om de componist Dvořák 
 gaat, en niet om de Amerikaanse uitvinder van een toetenbordindeling August 
 Dvorak. 
 (2 aardige details: 200 m verderop in Zwijndrecht ligt een straat met de naam 
 Kaartenmaker. En die Hoornse Dvořákhof heeft ook een eigenaardigheid: voor 
 een deel is van de straat waarvan de ene zijde Dvořákhof heet, en de andere 
 zijde Smetanahof. Wie verzint zoiets?)
 
 Verder: ook de naam van de Tsjechoslowaakse voorman van de Praagse Lente 
 Dubček op veel plaatsen ook verminkt tot Dubcek. En componist Béla Bartók 
 komt op alle mogelijke manier voor in de Nederlandse straatnamen. Met alleen 
 een accent op de e van Bela, met 2 accenten, geheel zonder accenten, en zelfs 
 -ongetwijfeld goedbedoeld- met een accent de verkeerde kant uit.
 
 Het geeft allemaal wel het belang aan van de flexibiliteit van geocoders en 
 andere straatnaamzoekers. Het zou rottig zijn als de hulpdiensten de route 
 naar de Dvořákhof niet weet te vinden omdat de brandweerman de r-met-haček 
 niet op zijn navigatiesysteem kan intoetsen.
 
 groet, 
 
 Gert-Jan van der Weijden (met streepje, puntjes op de ij etc.)
 
 -Oorspronkelijk bericht-
 Van: Pander OpenTaal [mailto:pan...@opentaal.org] 
 Verzonden: dinsdag 9 juni 2015 22:16
 Aan: OpenStreetMap NL discussion list; du...@lists.osgeo.org; 
 nlextr...@googlegroups.com; OpenGeoGroep Mailinglist
 Onderwerp: Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015
 
 On 04/26/2015 11:56 PM, Just van den Broecke wrote: 
 
 Sorry voor cross-posting.
 
 Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
 Top10NL via PDOK beschikbaar gekomen.
 
 NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
 beschikbaar gesteld:
 
 Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/ [1]
 BAG: http://data.nlextract.nl/bag [2] (ook CSV)
 
 Ik heb wat analyses gedaan op de export van BAG in CSV en heb de
 volgende fouten gevonden:
 
 ERROR dubbele spatie in straatnaam Burg. v. Dobben de Bruijnstraat
 ERROR dubbele spatie in straatnaam Burgemeester Groenenbergstraat
 ERROR dubbele spatie in straatnaam Wethouder M J van den Hatertstraat
 ERROR dubbele spatie in straatnaam Provinciale Weg
 ERROR dubbele spatie in straatnaam Burgemeester Wientjensstraat
 ERROR dubbele spatie in straatnaam Oranje Gelderlandlaan
 ERROR back quote in straatnaam `t Hoge Heem
 
 Kan iemand deze doorgeven aan de beheerder van BAG? Een van jullie zit
 vast dichter bij het vuur.
 
 De tien meest voorkomende straatnamen zijn:
 Dorpsstraat
 Kerkstraat
 Hoofdstraat
 Molenstraat
 Schoolstraat
 Nieuwstraat
 Wilhelminastraat
 Julianastraat
 Hoofdweg
 Stationsstraat
 
 Ik zal eens kijken welke straatnamen in de aankomende spellingcontrole
 nog op kunnen nemen
 
 Aantal opmerkelijke straatnamen met karakters die nergens anders worden
 gebruikt zijn:
 
 Örehof
 Önninkweg
 Öldersweg
 Salvador Dalístraat
 Estelístraat
 De Holtskòle
 Bartòk
 São Paulodreef
 São Paulostraat
 Ávilastraat
 Nîmeslaan
 Buñuellaan
 Laan van Køge
 Dvořákhof
 
 Van deze laatste is naar mijn idee de ř een brug te ver. Over het
 algemeen wordt een haček (behalve in het woord haček) in het Nederlands
 weggelaten. Wat vinden jullie?
 
 Groeten,
 
 Pander
 
 Hartelijke groet,
 
 --Just
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [3]
 
 -- 
 Stichting OpenTaal
 http://opentaal.org [4]
 http://twitter.com/opentaal [5]
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [3]
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [3]
 

Links:
--
[1] http://data.nlextract.nl/top10nl/postgis/apr2015/
[2] http://data.nlextract.nl/bag
[3] https://lists.openstreetmap.org/listinfo/talk-nl
[4] http

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Maarten Deen]

On 2015-06-10 15:27, Pander OpenTaal wrote:


Hoeveel fabrikanten van straatnaambordjes zijn er eigenlijk in
Nederland? Vanuit Stichting OpenTaal was ik al op zoek naar fabrikanten
van software voor borden voor wegwerkzaamheden maar dat liep op dood 
spoor.


Ik ken AGMI in Tegelen: http://www.agmi.nl/

Idee om met klein groepje vanuit OSM een overzicht hiervan te maken? 
Als
het enkele zijn zou dat ook wel een bezoekje waard zijn. Wie weet 
hebben
zij nog interesse in een webservice of procedureel advies die 
potentiële

fouten in straatnamen aangeeft.


Interessant is ook wie de database voor de onderschriften bij 
straatnamen beheert.


Maarten


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

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Pander OpenTaal]

On 06/10/2015 02:37 PM, Colin Smale wrote:
  
 
  
 
 De straat heet hoe de straat heet - spelfouten inbegrepen. De bron van
 de enige echte naamgeving is een gemeentelijk besluit. Dat wordt
 (hopelijk zonder fouten) overgenomen in de BAG. Ik weet niet waar degene
 kijkt die straatnaamborden bestelt, maar ook daar kan een foutje
 insluipen. En vervolgens kan de bordjesfabrikant ook een fout maken.
 Zeker als die gekke tekens niet makkelijk in te voeren zijn vanaf een
 normaal toetsenbord.
 
 Het is dus zaak om te achterhalen waar in de keten de fout is ontstaan,
 en het probleem op de juiste plek op te lossen.

Dit is ook een van de voordelen van open data, dat er meer mensen mee
kunnen helpen de kwaliteit te verbeteren.

Hoeveel fabrikanten van straatnaambordjes zijn er eigenlijk in
Nederland? Vanuit Stichting OpenTaal was ik al op zoek naar fabrikanten
van software voor borden voor wegwerkzaamheden maar dat liep op dood spoor.

Idee om met klein groepje vanuit OSM een overzicht hiervan te maken? Als
het enkele zijn zou dat ook wel een bezoekje waard zijn. Wie weet hebben
zij nog interesse in een webservice of procedureel advies die potentiële
fouten in straatnamen aangeeft.

Wat betreft het gemakkelijk invoeren van ongebruikelijke tekens op Linux
voor OSM-doeleinden, zie https://www.createspace.com/3758226

-

Gert-Jan, heb je (wij) interesse in een overzicht van straatnamen die
alleen in diakritisch teken verschillen? Kan eventueel einde van de naam
als straat, hof, laan, plein, etc. er eerst afgehaald worden. Vallen ook
die accenten die de verkeerde kant op staan eruit.

Speaking of which, is er ergens een overzicht van meest gangbare eindes
van straatnamen?

Wat betreft veiligheidsoverwegingen en gebruiksgemak zou ik persoonlijk
de haček afraden op een r. Voor namen van mensen uit Servië wordt deze
in kranten al nooit gebruikt (zie Milosovic versus Milosovič) maar weet
men meestal wel hoe het uit te spreken. Dus č, š en ž zijn goed om te
gebruiken.

Betreft de Tsjechische ř denk ik dat een op de 100.000 mensen in
Nederland deze niet eens correct kan uitspreken en dat is niet handig
als je hulpdiensten opbelt. Over de ř, ň, ě, ů en ł heb ik dan ook mijn
twijfels om die te gebruiken.

 
 //colin
 
 On 2015-06-10 14:08, Gert-Jan van der Weijden wrote:
 
 Leuk, die Dvořákhof (in Hoorn)!
 En mooi dat de volledige naam er wordt gebruikt, en geen verminking
 waarbij het Tsjechisch haakje (haček) wordt weggelaten.
 Strafpunten voor Zwijndrecht, dat botweg alle diakritische tekens in
 de naam van deze componist negeert.
 Uit het feit dat de Dvorakstraat in Zwijndrecht bij de Mozartlaan in
 de buurt ligt concludeer ik maar even dat het daadwerkelijk om de
 componist Dvořák gaat, en niet om de Amerikaanse uitvinder van een
 toetenbordindeling August Dvorak.
 (2 aardige details: 200 m verderop in Zwijndrecht ligt een straat met
 de naam Kaartenmaker. En die Hoornse Dvořákhof heeft ook een
 eigenaardigheid: voor een deel is van de straat waarvan de ene zijde
 Dvořákhof heet, en de andere zijde Smetanahof. Wie verzint zoiets?)

 Verder: ook de naam van de Tsjechoslowaakse voorman van de Praagse
 Lente Dubček op veel plaatsen ook verminkt tot Dubcek. En componist
 Béla Bartók komt op alle mogelijke manier voor in de Nederlandse
 straatnamen. Met alleen een accent op de e van Bela, met 2 accenten,
 geheel zonder accenten, en zelfs -ongetwijfeld goedbedoeld- met een
 accent de verkeerde kant uit.

 Het geeft allemaal wel het belang aan van de flexibiliteit van
 geocoders en andere straatnaamzoekers. Het zou rottig zijn als de
 hulpdiensten de route naar de Dvořákhof niet weet te vinden omdat de
 brandweerman de r-met-haček niet op zijn navigatiesysteem kan intoetsen.


 groet,

 Gert-Jan van der Weijden (met streepje, puntjes op de ij etc.)





 -Oorspronkelijk bericht-
 Van: Pander OpenTaal [mailto:pan...@opentaal.org
 mailto:pan...@opentaal.org]
 Verzonden: dinsdag 9 juni 2015 22:16
 Aan: OpenStreetMap NL discussion list; du...@lists.osgeo.org
 mailto:du...@lists.osgeo.org; nlextr...@googlegroups.com
 mailto:nlextr...@googlegroups.com; OpenGeoGroep Mailinglist
 Onderwerp: Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

 On 04/26/2015 11:56 PM, Just van den Broecke wrote:
 Sorry voor cross-posting.

 Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
 Top10NL via PDOK beschikbaar gekomen.

 NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
 beschikbaar gesteld:

 Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
 BAG: http://data.nlextract.nl/bag (ook CSV)

 Ik heb wat analyses gedaan op de export van BAG in CSV en heb de
 volgende fouten gevonden:

 ERROR dubbele spatie in straatnaam Burg. v. Dobben de  Bruijnstraat
 ERROR dubbele spatie in straatnaam Burgemeester  Groenenbergstraat
 ERROR dubbele spatie in straatnaam Wethouder M J van den  Hatertstraat
 ERROR dubbele spatie in straatnaam Provinciale  Weg
 ERROR dubbele spatie in straatnaam

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[St Niklaas]

Beste Maarten Deen,
 
Onderstaand het mail adres van de vereniging van borden fabrikanten in 
Nederland.
 
i...@vnvf.nl
 
Ik ben benieuwd, mijn vorige poging om het digitale bordenboek voor OSM binnen 
te halen strandde op u kunt het kopen, zonder een afspraak aangaande de rechten 
van de plaatjes.
 
Hendrikklaas 
 
Voor een bezichtiging kun je beter een fabrikant uit  de onderstaande lijst 
benaderen;
 
http://www.vnvf.nl/links/
 
succes

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

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Pander OpenTaal]

On 04/26/2015 11:56 PM, Just van den Broecke wrote:
 Sorry voor cross-posting.
 
 Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
 Top10NL via PDOK beschikbaar gekomen.
 
 NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
 beschikbaar gesteld:
 
 Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
 BAG: http://data.nlextract.nl/bag (ook CSV)

Ik heb wat analyses gedaan op de export van BAG in CSV en heb de
volgende fouten gevonden:

ERROR dubbele spatie in straatnaam Burg. v. Dobben de  Bruijnstraat
ERROR dubbele spatie in straatnaam Burgemeester  Groenenbergstraat
ERROR dubbele spatie in straatnaam Wethouder M J van den  Hatertstraat
ERROR dubbele spatie in straatnaam Provinciale  Weg
ERROR dubbele spatie in straatnaam Burgemeester  Wientjensstraat
ERROR dubbele spatie in straatnaam Oranje  Gelderlandlaan
ERROR back quote in straatnaam `t Hoge Heem

Kan iemand deze doorgeven aan de beheerder van BAG? Een van jullie zit
vast dichter bij het vuur.



De tien meest voorkomende straatnamen zijn:
Dorpsstraat
Kerkstraat
Hoofdstraat
Molenstraat
Schoolstraat
Nieuwstraat
Wilhelminastraat
Julianastraat
Hoofdweg
Stationsstraat

Ik zal eens kijken welke straatnamen in de aankomende spellingcontrole
nog op kunnen nemen

Aantal opmerkelijke straatnamen met karakters die nergens anders worden
gebruikt zijn:

Örehof
Önninkweg
Öldersweg
Salvador Dalístraat
Estelístraat
De Holtskòle
Bartòk
São Paulodreef
São Paulostraat
Ávilastraat
Nîmeslaan
Buñuellaan
Laan van Køge
Dvořákhof

Van deze laatste is naar mijn idee de ř een brug te ver. Over het
algemeen wordt een haček (behalve in het woord haček) in het Nederlands
weggelaten. Wat vinden jullie?

Groeten,

Pander

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


-- 
Stichting OpenTaal
http://opentaal.org
http://twitter.com/opentaal

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

Re: [OSM-talk-nl] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Tijmen Stam]

Is er een Nederlandse OSM-stichting waar ik het bord Groenlandse Kade 
aan kan doneren?


De gemeente belt dat ze de borden gaan verwijderen omdat de juiste 
schrijfwijze Groenlandsekade is :-)


Ik wacht nog even af tot de situatie op de grond ook zo is, en dan maak 
ik er Groenlandsekade van.


Tijmen

On 01-06-15 21:23, Tijmen Stam wrote:

On 01-06-15 08:51, Christ van Willegen wrote:

2015-05-31 14:32 GMT+02:00 Gert-Jan van der Weijden gee...@dds.nl:

De theorie:
In de traditie van René Magritte (Ceci n'est pas une pipe) en
Alfred Korzybski
(The map is not the territory) kun je redeneren dat de tekst op een
straatnaambord niet de straatnaam zélf is, maar slechts een indicatie
van de
straatnaam.


Zoals bij mij in de wijk. Ik zie daar borden met Finisterelaan,
Finistèrelaan
en Finisterèlaan...


Ik heb de gemeente gemaild, eens zien wat daar uit komt.

Ik werk bij Connexxion, en omdat onze apparatuur nog uit de oertijd
stamt toen Unicode nog niet bestond, hebben we besloten geen accenten
e.d. in bushaltes op te nemen. Daarom staat op onze site Bethanie ipv
Bethanië en vroeger Ariensplein ipv Ariënsplein.

Maar namen zijn complex. Zo staat in het Overzicht van de Nederlandse
spoor- en tramwegbedrijven door ir. J.W. Sluiter een voetnoot
De gemeente heet Borsele, het dorp Borssele en het station was
Borsselen..

Tijmen

___
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 vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Johan C]

Mooi resultaat Tijmen!

OSM Nederland heeft nog geen stichting, maar je kunt het bord misschien wel
kwijt bij OSGeo.nl :-)

Gr., Johan

Op 2 juni 2015 21:10 schreef Tijmen Stam mailingli...@iivq.net:

 Is er een Nederlandse OSM-stichting waar ik het bord Groenlandse Kade
 aan kan doneren?

 De gemeente belt dat ze de borden gaan verwijderen omdat de juiste
 schrijfwijze Groenlandsekade is :-)

 Ik wacht nog even af tot de situatie op de grond ook zo is, en dan maak ik
 er Groenlandsekade van.

 Tijmen


 On 01-06-15 21:23, Tijmen Stam wrote:

 On 01-06-15 08:51, Christ van Willegen wrote:

 2015-05-31 14:32 GMT+02:00 Gert-Jan van der Weijden gee...@dds.nl:

 De theorie:
 In de traditie van René Magritte (Ceci n'est pas une pipe) en
 Alfred Korzybski
 (The map is not the territory) kun je redeneren dat de tekst op een
 straatnaambord niet de straatnaam zélf is, maar slechts een indicatie
 van de
 straatnaam.


 Zoals bij mij in de wijk. Ik zie daar borden met Finisterelaan,
 Finistèrelaan
 en Finisterèlaan...


 Ik heb de gemeente gemaild, eens zien wat daar uit komt.

 Ik werk bij Connexxion, en omdat onze apparatuur nog uit de oertijd
 stamt toen Unicode nog niet bestond, hebben we besloten geen accenten
 e.d. in bushaltes op te nemen. Daarom staat op onze site Bethanie ipv
 Bethanië en vroeger Ariensplein ipv Ariënsplein.

 Maar namen zijn complex. Zo staat in het Overzicht van de Nederlandse
 spoor- en tramwegbedrijven door ir. J.W. Sluiter een voetnoot
 De gemeente heet Borsele, het dorp Borssele en het station was
 Borsselen..

 Tijmen

 ___
 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] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Christ van Willegen]

2015-05-31 14:32 GMT+02:00 Gert-Jan van der Weijden gee...@dds.nl:
 De theorie:
 In de traditie van René Magritte (Ceci n'est pas une pipe) en Alfred 
 Korzybski
 (The map is not the territory) kun je redeneren dat de tekst op een
 straatnaambord niet de straatnaam zélf is, maar slechts een indicatie van de
 straatnaam.

Zoals bij mij in de wijk. Ik zie daar borden met Finisterelaan,
Finistèrelaan
en Finisterèlaan...

Christ van Willegen

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

Re: [OSM-talk-nl] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Tijmen Stam]

On 01-06-15 08:51, Christ van Willegen wrote:

2015-05-31 14:32 GMT+02:00 Gert-Jan van der Weijden gee...@dds.nl:

De theorie:
In de traditie van René Magritte (Ceci n'est pas une pipe) en Alfred Korzybski
(The map is not the territory) kun je redeneren dat de tekst op een
straatnaambord niet de straatnaam zélf is, maar slechts een indicatie van de
straatnaam.


Zoals bij mij in de wijk. Ik zie daar borden met Finisterelaan,
Finistèrelaan
en Finisterèlaan...


Ik heb de gemeente gemaild, eens zien wat daar uit komt.

Ik werk bij Connexxion, en omdat onze apparatuur nog uit de oertijd 
stamt toen Unicode nog niet bestond, hebben we besloten geen accenten 
e.d. in bushaltes op te nemen. Daarom staat op onze site Bethanie ipv 
Bethanië en vroeger Ariensplein ipv Ariënsplein.


Maar namen zijn complex. Zo staat in het Overzicht van de Nederlandse 
spoor- en tramwegbedrijven door ir. J.W. Sluiter een voetnoot

De gemeente heet Borsele, het dorp Borssele en het station was Borsselen..

Tijmen

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

Re: [OSM-talk-nl] BAG vs On-The-Ground

[Johan C]

Het beste blijft, lijkt me, contact opnemen met de gemeente en de
verschillen bij hen aangeven. Uiteraard heb je een punt dat niet alleen
straatnaamborden maar eventueel ook de BAG fout zou kunnen zijn (fout =
afwijken van het formele besluit). Mocht je met Gemeente Woerden contact
opnemen, dan ben ik benieuwd naar de uitkomst daarvan.

Cheers, Johan

Op 31 mei 2015 19:50 schreef Colin Smale colin.sm...@xs4all.nl:




 En als de BAG niet overeenkomt met het formele Straatnaambesluit,
 bijvoorbeeld a.g.v. een typfout? Volgens mij prevaleert dan het Besluit en
 moet de BAG worden bijgewerkt. Het is dus niet voldoende om alleen de BAG
 te raadplegen - je moet het Straatnaambesluit bij de gemeente opvragen.
 Misschien zijn de borden wel goed, en de BAG niet.

 Het spreekt voor zich (IMHO) dat de straatnaam op de adres-nodes overeen
 moet komen met de straatnaam op de weg waar het adres bij hoort. Als de
 naam op de weg wordt aangepast omdat ik de OTG-regel toepas, hoe kan ik het
 verband tussen de adres-nodes en de weg handhaven? We kunnen dit doen door
 ook de adres-nodes aan te passen, maar dan is de bron van de naam niet
 langer de BAG maar survey bijvoorbeeld.

 //colin



 On 2015-05-31 14:11, Johan C wrote:

 1. OSM heeft ook het principe dat afkortingen voluit geschreven moeten
 worden in tegenstelling tot naamgeving op borden
 2. Op het forum zijn ook al eens gevallen langsgekomen waarbij de naam van
 een straat op meerdere borden in die straat verschillend geschreven werd
 3. Aangezien gemeenten zich behoren te houden aan de BAG zou de beste
 oplossing zijn om gemeenten te wijzen op hun fout en hen de kans geven om
 binnen een redelijke termijn de bebording te vervangen

 Cheers, Johan

 Op 31 mei 2015 12:37 schreef Sebastiaan Couwenberg sebas...@xs4all.nl:

 On 05/31/2015 12:14 PM, Colin Smale wrote:
  Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
  Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
  de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
  dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw
  ik in deze gevallen de borden als correcter dan de BAG. Degene die de
  BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
  straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
  niet langer met de borden en de conventies.
 
  Dus hebben we een situatie geschapen waarbij een officieel register
  zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
  overschrijden we één van de basisbeginselen van OSM.
 
  Wat vindt men hier zoal van?

 Het on-the-ground principe voor de extacte schrijfwijze van borden weegt
 wat mij betreft niet zo zwaar.

 De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk
 van voor de tijd dat dit een wettelijk plicht was. Of wijken hier van af
 ivm beperkte ruimte op de borden.

 Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima
 acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak
 en estetische waarde.

 Mvg,

 Bas

 --
  GPG Key ID: 4096R/6750F10AE88D4AF1
 Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

 ___
 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


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

Re: [OSM-talk-nl] BAG vs On-The-Ground

[Colin Smale]

 

En als de BAG niet overeenkomt met het formele Straatnaambesluit,
bijvoorbeeld a.g.v. een typfout? Volgens mij prevaleert dan het Besluit
en moet de BAG worden bijgewerkt. Het is dus niet voldoende om alleen de
BAG te raadplegen - je moet het Straatnaambesluit bij de gemeente
opvragen. Misschien zijn de borden wel goed, en de BAG niet. 

Het spreekt voor zich (IMHO) dat de straatnaam op de adres-nodes overeen
moet komen met de straatnaam op de weg waar het adres bij hoort. Als de
naam op de weg wordt aangepast omdat ik de OTG-regel toepas, hoe kan ik
het verband tussen de adres-nodes en de weg handhaven? We kunnen dit
doen door ook de adres-nodes aan te passen, maar dan is de bron van de
naam niet langer de BAG maar survey bijvoorbeeld. 

//colin 

On 2015-05-31 14:11, Johan C wrote: 

 1. OSM heeft ook het principe dat afkortingen voluit geschreven moeten worden 
 in tegenstelling tot naamgeving op borden 
 2. Op het forum zijn ook al eens gevallen langsgekomen waarbij de naam van 
 een straat op meerdere borden in die straat verschillend geschreven werd 
 3. Aangezien gemeenten zich behoren te houden aan de BAG zou de beste 
 oplossing zijn om gemeenten te wijzen op hun fout en hen de kans geven om 
 binnen een redelijke termijn de bebording te vervangen 
 
 Cheers, Johan 
 
 Op 31 mei 2015 12:37 schreef Sebastiaan Couwenberg sebas...@xs4all.nl:
 
 On 05/31/2015 12:14 PM, Colin Smale wrote:
 Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
 Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
 de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
 dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw
 ik in deze gevallen de borden als correcter dan de BAG. Degene die de
 BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
 straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
 niet langer met de borden en de conventies.
 
 Dus hebben we een situatie geschapen waarbij een officieel register
 zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
 overschrijden we één van de basisbeginselen van OSM.
 
 Wat vindt men hier zoal van?
 
 Het on-the-ground principe voor de extacte schrijfwijze van borden weegt
 wat mij betreft niet zo zwaar.
 
 De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk
 van voor de tijd dat dit een wettelijk plicht was. Of wijken hier van af
 ivm beperkte ruimte op de borden.
 
 Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima
 acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak
 en estetische waarde.
 
 Mvg,
 
 Bas
 
 --
 GPG Key ID: 4096R/6750F10AE88D4AF1
 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [1]
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [1]
 

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

[OSM-talk-nl] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Colin Smale]

 

Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw
ik in deze gevallen de borden als correcter dan de BAG. Degene die de
BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
niet langer met de borden en de conventies. 

Dus hebben we een situatie geschapen waarbij een officieel register
zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
overschrijden we één van de basisbeginselen van OSM. 

Wat vindt men hier zoal van? 

//colin 

On 2015-05-29 23:37, Colin Smale wrote: 

 Heb je de gemeente geraadpleegd? Waarschijnlijk heeft de hele straat dezelfde 
 schrijfwijze in het officiele Straatnaambesluit en hebben sindsdien 
 verschillende partijen ongecontroleerd verschillende schrijfwijzen 
 gehanteerd. 
 
 Wat mij logisch lijkt is hetzij Groenlandse Kade hetzij Groenlandsekade. 
 Mijn taalkundige intuitie neigt naar de eerste maar met straatnamen weet je 
 het nooit tegenwoordig. 
 
 Hoe dan ook, één schrijfwijze is juist voor de hele straat, en de rest is 
 fout - ook al zitten die fouten ook op borden en in de BAG. Gelukkig scheelt 
 het in dit geval maar heel weinig - het zal voor mensen geen problemen 
 opleveren. Maar computers zijn niet zo snugger... 
 
 //Colin 
 
 On 2015-05-29 23:12, Tijmen Stam wrote: 
 
 Hallo,
 
 2 vragen over de Groenlandse[ K|k]ade in Vinkeveen.
 
 1. Ik heb vaak gelezen Map what's on the ground. Hoe ga je om met een 
 straat die 3 straatnaambordjes heeft, 2x Groenlandse Kade (beiden redelijk 
 nieuw), 1x Groenlandsekade (ouder), maar de BAG-viewer geeft wel aan 
 Groenlandsekade? De Site van de gemeente geeft Groenlandse kade (met 
 spatie, zonder hoofdletter, zie 
 http://www.derondevenen.nl/servicebalie/meldpunt-openbare-ruimte_3253/ [1])
 
 Op OSM komen beide varianten voor, de weg is ook in stukjes opgeknipt met 
 verschillende naam, zie 
 http://www.openstreetmap.org/search?query=groenlandsekade#map=18/52.22754/4.97983layers=N
  [2] en 
 http://www.openstreetmap.org/search?query=groenlandse+kade#map=18/52.22754/4.97983layers=N
  [3]
 
 2. Langs de Groenlandse[ K|k]ade liggen veel woningen met het adres volledig 
 ingevuld, maar als naam Groenlandsekade. Het adres zit op een losse node. 
 Zie bijv http://www.openstreetmap.org/node/2878199639 [4]
 
 addr:city Vinkeveen
 addr:housenumber 61
 addr:postcode 3645BB
 addr:street Groenlandse kade
 name Groenlandsekade
 source BAG
 source:date 2014-05-24
 
 De name tag hoort toch helemaal niet op deze adresnode?
 In het geval van http://www.openstreetmap.org/way/284043319 [5] lijkt OSM 
 er zelfs de voorkeur aan te geven om de name ipv het housenumber te 
 renderen, dit staat op de kaart als Groenlandsekade ipv als 19A.
 
 Tijmen
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [6]
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [6]
 

Links:
--
[1]
http://www.derondevenen.nl/servicebalie/meldpunt-openbare-ruimte_3253/
[2]
http://www.openstreetmap.org/search?query=groenlandsekade#map=18/52.22754/4.97983amp;layers=N
[3]
http://www.openstreetmap.org/search?query=groenlandse+kade#map=18/52.22754/4.97983amp;layers=N
[4] http://www.openstreetmap.org/node/2878199639
[5] http://www.openstreetmap.org/way/284043319
[6] 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 vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Pander]

Is er een plek in de import om adhv regex een rapport te genereren net alle 
waarschijnlijk afwijkende/verkeerde schrijfwijzes? 

On 31 May 2015 12:14:43 CEST, Colin Smale colin.sm...@xs4all.nl wrote:
 

Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
dat alle woorden in een straatnaam een hoofdletter krijgen, dus
beschouw
ik in deze gevallen de borden als correcter dan de BAG. Degene die de
BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
niet langer met de borden en de conventies. 

Dus hebben we een situatie geschapen waarbij een officieel register
zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
overschrijden we één van de basisbeginselen van OSM. 

Wat vindt men hier zoal van? 

//colin 

On 2015-05-29 23:37, Colin Smale wrote: 

 Heb je de gemeente geraadpleegd? Waarschijnlijk heeft de hele straat
dezelfde schrijfwijze in het officiele Straatnaambesluit en hebben
sindsdien verschillende partijen ongecontroleerd verschillende
schrijfwijzen gehanteerd. 
 
 Wat mij logisch lijkt is hetzij Groenlandse Kade hetzij
Groenlandsekade. Mijn taalkundige intuitie neigt naar de eerste maar
met straatnamen weet je het nooit tegenwoordig. 
 
 Hoe dan ook, één schrijfwijze is juist voor de hele straat, en de
rest is fout - ook al zitten die fouten ook op borden en in de BAG.
Gelukkig scheelt het in dit geval maar heel weinig - het zal voor
mensen geen problemen opleveren. Maar computers zijn niet zo snugger...

 
 //Colin 
 
 On 2015-05-29 23:12, Tijmen Stam wrote: 
 
 Hallo,
 
 2 vragen over de Groenlandse[ K|k]ade in Vinkeveen.
 
 1. Ik heb vaak gelezen Map what's on the ground. Hoe ga je om met
een straat die 3 straatnaambordjes heeft, 2x Groenlandse Kade (beiden
redelijk nieuw), 1x Groenlandsekade (ouder), maar de BAG-viewer geeft
wel aan Groenlandsekade? De Site van de gemeente geeft Groenlandse
kade (met spatie, zonder hoofdletter, zie
http://www.derondevenen.nl/servicebalie/meldpunt-openbare-ruimte_3253/
[1])
 
 Op OSM komen beide varianten voor, de weg is ook in stukjes
opgeknipt met verschillende naam, zie
http://www.openstreetmap.org/search?query=groenlandsekade#map=18/52.22754/4.97983layers=N
[2] en
http://www.openstreetmap.org/search?query=groenlandse+kade#map=18/52.22754/4.97983layers=N
[3]
 
 2. Langs de Groenlandse[ K|k]ade liggen veel woningen met het adres
volledig ingevuld, maar als naam Groenlandsekade. Het adres zit op
een losse node. Zie bijv http://www.openstreetmap.org/node/2878199639
[4]
 
 addr:city Vinkeveen
 addr:housenumber 61
 addr:postcode 3645BB
 addr:street Groenlandse kade
 name Groenlandsekade
 source BAG
 source:date 2014-05-24
 
 De name tag hoort toch helemaal niet op deze adresnode?
 In het geval van http://www.openstreetmap.org/way/284043319 [5]
lijkt OSM er zelfs de voorkeur aan te geven om de name ipv het
housenumber te renderen, dit staat op de kaart als Groenlandsekade
ipv als 19A.
 
 Tijmen
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [6]
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-nl [6]
 

Links:
--
[1]
http://www.derondevenen.nl/servicebalie/meldpunt-openbare-ruimte_3253/
[2]
http://www.openstreetmap.org/search?query=groenlandsekade#map=18/52.22754/4.97983amp;layers=N
[3]
http://www.openstreetmap.org/search?query=groenlandse+kade#map=18/52.22754/4.97983amp;layers=N
[4] http://www.openstreetmap.org/node/2878199639
[5] http://www.openstreetmap.org/way/284043319
[6] https://lists.openstreetmap.org/listinfo/talk-nl




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

--
Stichting OpenTaal
http://opentaal.org___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Sebastiaan Couwenberg]

On 05/31/2015 12:14 PM, Colin Smale wrote:
 Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
 Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
 de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
 dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw
 ik in deze gevallen de borden als correcter dan de BAG. Degene die de
 BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
 straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
 niet langer met de borden en de conventies. 
 
 Dus hebben we een situatie geschapen waarbij een officieel register
 zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
 overschrijden we één van de basisbeginselen van OSM. 
 
 Wat vindt men hier zoal van? 

Het on-the-ground principe voor de extacte schrijfwijze van borden weegt
wat mij betreft niet zo zwaar.

De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk
van voor de tijd dat dit een wettelijk plicht was. Of wijken hier van af
ivm beperkte ruimte op de borden.

Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima
acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak
en estetische waarde.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Gert-Jan van der Weijden]

De theorie:
In de traditie van René Magritte (Ceci n'est pas une pipe) en Alfred 
Korzybski (The map is not the territory) kun je redeneren dat de tekst op een 
straatnaambord niet de straatnaam zélf is, maar slechts een indicatie van de 
straatnaam. Als je de letterlijke tekst op een straatnaambord (inclusief daarop 
voorkomende typefouten/afkortingen/hoistorische toelichting etc.) wilt taggen 
zou je de borden zélf moeten gaan taggen.

Aan de andere kant: bij de BAG import hebben we geen gebruik gemaakt van de tag 
associatedStreet, dus de adressen zélf hebben in princiep altijd wel de formeel 
juiste straatnaam. 
Met de BAG import zijn inderdaad de verschillen tussen de geïmporteerde 
adressen en de ground-truth straatnamen aangepast.
Om eerlijk te zijn kan ik -op het forum- niet meer terugvinden waarom die 
laatste stap is toegevoegd, en we niet voor lief hebben genomen dat er verschil 
kan bestaan tussen een straatnaam in OSM en de straatnaam zoals opgenomen in de 
adressen aan die straat.
Wellicht dat een parallelpost naar het forum hier bij kan helpen.


De praktijk: 
Net zoals Bas zou ik er vooral praktisch mee omgaan. 
Dat doen gemeenten ook, die passen straatnamen in de BAG ook niet direct aan 
als er een typefout in blijkt te zitten. En nemen daarmee voor lief dat 
straatnaamborden en BAG-namen niet 100% overeenstemmen



groet, 

Gert-Jan





-Oorspronkelijk bericht-
Van: Sebastiaan Couwenberg [mailto:sebas...@xs4all.nl] 
Verzonden: zondag 31 mei 2015 12:38
Aan: talk-nl@openstreetmap.org
Onderwerp: Re: [OSM-talk-nl] BAG vs On-The-Ground (Was: 
Groenlandsekade/Groenlandse Kade, Vinkeveen)

On 05/31/2015 12:14 PM, Colin Smale wrote:
 Ook in Woerden doet zich dit voor. Botnische golf, Middelandse 
 zee, Finse golf hebben een afwijking tussen de schrijfwijze volgens 
 BAG en de schrijfwijze op de borden ter plaatse. De conventie in 
 Nederland is dat alle woorden in een straatnaam een hoofdletter 
 krijgen, dus beschouw ik in deze gevallen de borden als correcter dan 
 de BAG. Degene die de BAG-import heeft gedaan heeft de import-regels 
 netjes opgevolgd en deze straatnamen verbeterd zodat ze nu wel 
 overeenstemmen met de BAG, maar niet langer met de borden en de conventies.
 
 Dus hebben we een situatie geschapen waarbij een officieel register 
 zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee 
 overschrijden we één van de basisbeginselen van OSM.
 
 Wat vindt men hier zoal van? 

Het on-the-ground principe voor de extacte schrijfwijze van borden weegt wat 
mij betreft niet zo zwaar.

De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk van voor 
de tijd dat dit een wettelijk plicht was. Of wijken hier van af ivm beperkte 
ruimte op de borden.

Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima 
acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak en 
estetische waarde.

Mvg,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

___
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 vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Johan C]

1. OSM heeft ook het principe dat afkortingen voluit geschreven moeten
worden in tegenstelling tot naamgeving op borden
2. Op het forum zijn ook al eens gevallen langsgekomen waarbij de naam van
een straat op meerdere borden in die straat verschillend geschreven werd
3. Aangezien gemeenten zich behoren te houden aan de BAG zou de beste
oplossing zijn om gemeenten te wijzen op hun fout en hen de kans geven om
binnen een redelijke termijn de bebording te vervangen

Cheers, Johan

Op 31 mei 2015 12:37 schreef Sebastiaan Couwenberg sebas...@xs4all.nl:

 On 05/31/2015 12:14 PM, Colin Smale wrote:
  Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
  Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
  de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
  dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw
  ik in deze gevallen de borden als correcter dan de BAG. Degene die de
  BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
  straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
  niet langer met de borden en de conventies.
 
  Dus hebben we een situatie geschapen waarbij een officieel register
  zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
  overschrijden we één van de basisbeginselen van OSM.
 
  Wat vindt men hier zoal van?

 Het on-the-ground principe voor de extacte schrijfwijze van borden weegt
 wat mij betreft niet zo zwaar.

 De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk
 van voor de tijd dat dit een wettelijk plicht was. Of wijken hier van af
 ivm beperkte ruimte op de borden.

 Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima
 acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak
 en estetische waarde.

 Mvg,

 Bas

 --
  GPG Key ID: 4096R/6750F10AE88D4AF1
 Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

 ___
 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

[OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Just van den Broecke]

Sorry voor cross-posting.

Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT 
Top10NL via PDOK beschikbaar gekomen.


NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download 
beschikbaar gesteld:


Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
BAG: http://data.nlextract.nl/bag (ook CSV)

Hartelijke groet,

--Just





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

[OSM-talk-nl] BAG import nacontrole

[Maarten Deen]

Ik kwam toevallig in Blerick een groot aantal unconnected nodes tegen. 
Na wat verder zoeken zag ik ook wat oude 3dshapes buildings nog over de 
nieuwere BAG gebouwen liggen. Ik neem dus aan dat hier een BAG import 
niet helemaal goed gegaan is.
De BAG import daar was van juni, dus ik heb alles maar een beetje 
opgeruimd.
keepright laat het mooi zien 
http://keepright.at/report_map.php?zoom=16lat=51.37323lon=6.14222layers=B0Tch=0%2C70%2C20show_ign=1show_tmpign=1

(zolang de data niet geupdate wordt).

Toen ben ik verder gaan kijken. In Melick kwam ik ze ook tegen. In 
Herkenbosch waren alle adres nodes dubbel. Ik ben nu in Sittard bezig 
met unconnected nodes.


Ik denk dat het een goed idee is om met zijn allen keepright even te 
gebruiken en zo wat overtollige nodes te verwijderen. Mijn settings op 
dit moment zijn om alleen missing tags en multiple nodes on the same 
spot te zien. Let me die laatste op dat je geen GSM masten verwijdert.


Kan iemand dit ook even op het forum wil posten?

Groeten,
Maarten


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

Re: [OSM-talk-nl] BAG import nacontrole

[Sebastiaan Couwenberg]

On 07/25/2014 12:11 PM, Maarten Deen wrote:
 Kan iemand dit ook even op het forum wil posten?

Done: http://forum.openstreetmap.org/viewtopic.php?id=26440

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

[OSM-talk-nl] BAG import

[Johan C]

Zo'n 5,5 maand na een discussie over de BAG import heeft Frederik Ramm
afgelopen vrijdag een opmerking gemaakt over de import. Ben je
geinteresserd in discussies over de trias politica, de handelwijze van
dictators, functievermenging, governance, transparantie, de onvolwassenheid
van OSM, beslissingsmethoden en nog veel meer, kijk dan naar de posts die
sinds afgelopen vrijdag op het NL forum zijn gezet

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

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

[Just van den Broecke]

(kan hopelijk e.e.a. verhelderen rond BAG WFS)

On 29-05-13 23:46, Jo wrote:

Op 29 mei 2013 14:45 schreef Gertjan Idema g.id...@zonnet.nl
mailto:g.id...@zonnet.nl het volgende:

__
On Wed, 2013-05-29 at 14:26 +0200, Jo wrote:

Ik kan niet beloven dat ik er tijd voor heb (ben al wat teveel
hooi op m'n vork aan het nemen), maar ik zou hier wel eens naar
willen kijken.

Als je mee wilt denken graag.


Waar kan ik de adresgegevens voor 1 gemeente afhalen als SHP of
WFS? Of staan ze in een ander formaat?


De URL van de WFS server is
http://geodata.nationaalgeoregister.nl/bagviewer/wfs
De feature voor de adressen is 'verblijfsobject'

Met feature 'woonplaats' kan je eventueel een polygoon van een
woonplaats opvragen


Ik heb die WFS benaderd met QGIS. Ik begrijp niet helemaal waarom ik
maar 3 'kluitjes' adressen te zien krijg.
De WFS http://geodata.nationaalgeoregister.nl/bagviewer/wfs is een 
experimentele PDOK service onstaan bij gebrek aan een 'echte' BAG 
service. Origineel was deze service uitsluitend bedoeld voor de 
BAGViewer: http://bagviewer.geodan.nl. Maar goed, het is de enige BAG 
(data) service op dit moment in PDOK. Er is nog een WMS: 
http://geodata.nationaalgeoregister.nl/inspireadressen/wms die puur 
adressen bevat van zowel Verblijfsobjecten, Ligplaatsen en Standplaatsen 
alleen is daar geen WFS van. Later dit jaar komt nog de INSPIRE 
Addresses WFS (geen gebouwen).


3 'kluitjes' adressen komt m.i. omdat er een harde limiet van 15000 
objecten in een GetFeature response op de WFS staat (en elke WFS in PDOK).


Ik werk zelf niet meer aan PDOK maar wel aan clients die mogelijk handig 
zijn, vanuit Heron: http://heron-mc.org, bijv om plaatselijk BAG 
adressen te vinden en te downloaden:


http://lib.heron-mc.org/heron/0.73rc3/examples/querybuildernl of 
verschillende zoekmethoden:

http://lib.heron-mc.org/heron/0.73rc3/examples/multisearchcenternl

Maar goed, zoals gezegd: het downloaden is het gemakkelijkste gedeelte ;-).

groeten,

Just


Deze opslaan als SHP is geen probleem. Dat SHP bestand openen in JOSM
gaat ook probleemloos. Dan alles selecteren en wat tags weggooien en
andere volgens de OSM-conventies zetten.

OK, dat was het gemakkelijkste gedeelte...




De gebouwen zitten al in OSM, vermoed ik?


De BAG gebouwen zitten nog niet in OSM. Wat er nu in OSM zit zijn
huizenblokken uit de 3dshapes import. Deze zijn minder gedetailleerd.


Als die gewoon weg mogen, zou het ook nog relatief eenvoudig moeten zijn
om die data over te brengen. Als de historiek best behouden blijft,
wordt het toch wel handwerk. Al ben ik op iets aan het broeden om dat
binnen JOSM te automatiseren.

Ik heb al een Pythonscript gemaakt dat meteen ook zorgt voor het
aanmaken van associatedStreetrelaties bij het omzetten van SHP naar OSM.
De data voor Brussel is ook vrijgegeven en dat had ik daarvoor gemaakt,
maar het kan gemakkelijk aangepast worden aan de tags die in de BAG
gebruikt worden.

Jo


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://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] BAG gegevens Re: OSM Navigatieapparatuur

[Just van den Broecke]

Correctie: er is wel een BAG adressen WFS:
http://geodata.nationaalgeoregister.nl/inspireadressen/wfs?
gr

Just
On 30-05-13 11:10, Just van den Broecke wrote:


(kan hopelijk e.e.a. verhelderen rond BAG WFS)

On 29-05-13 23:46, Jo wrote:

Op 29 mei 2013 14:45 schreef Gertjan Idema g.id...@zonnet.nl
mailto:g.id...@zonnet.nl het volgende:

__
On Wed, 2013-05-29 at 14:26 +0200, Jo wrote:

Ik kan niet beloven dat ik er tijd voor heb (ben al wat teveel
hooi op m'n vork aan het nemen), maar ik zou hier wel eens naar
willen kijken.

Als je mee wilt denken graag.


Waar kan ik de adresgegevens voor 1 gemeente afhalen als SHP of
WFS? Of staan ze in een ander formaat?


De URL van de WFS server is
http://geodata.nationaalgeoregister.nl/bagviewer/wfs
De feature voor de adressen is 'verblijfsobject'

Met feature 'woonplaats' kan je eventueel een polygoon van een
woonplaats opvragen


Ik heb die WFS benaderd met QGIS. Ik begrijp niet helemaal waarom ik
maar 3 'kluitjes' adressen te zien krijg.

De WFS http://geodata.nationaalgeoregister.nl/bagviewer/wfs is een
experimentele PDOK service onstaan bij gebrek aan een 'echte' BAG
service. Origineel was deze service uitsluitend bedoeld voor de
BAGViewer: http://bagviewer.geodan.nl. Maar goed, het is de enige BAG
(data) service op dit moment in PDOK. Er is nog een WMS:
http://geodata.nationaalgeoregister.nl/inspireadressen/wms die puur
adressen bevat van zowel Verblijfsobjecten, Ligplaatsen en Standplaatsen
alleen is daar geen WFS van. Later dit jaar komt nog de INSPIRE
Addresses WFS (geen gebouwen).

3 'kluitjes' adressen komt m.i. omdat er een harde limiet van 15000
objecten in een GetFeature response op de WFS staat (en elke WFS in PDOK).

Ik werk zelf niet meer aan PDOK maar wel aan clients die mogelijk handig
zijn, vanuit Heron: http://heron-mc.org, bijv om plaatselijk BAG
adressen te vinden en te downloaden:

http://lib.heron-mc.org/heron/0.73rc3/examples/querybuildernl of
verschillende zoekmethoden:
http://lib.heron-mc.org/heron/0.73rc3/examples/multisearchcenternl

Maar goed, zoals gezegd: het downloaden is het gemakkelijkste gedeelte ;-).

groeten,

Just


Deze opslaan als SHP is geen probleem. Dat SHP bestand openen in JOSM
gaat ook probleemloos. Dan alles selecteren en wat tags weggooien en
andere volgens de OSM-conventies zetten.

OK, dat was het gemakkelijkste gedeelte...




De gebouwen zitten al in OSM, vermoed ik?


De BAG gebouwen zitten nog niet in OSM. Wat er nu in OSM zit zijn
huizenblokken uit de 3dshapes import. Deze zijn minder gedetailleerd.


Als die gewoon weg mogen, zou het ook nog relatief eenvoudig moeten zijn
om die data over te brengen. Als de historiek best behouden blijft,
wordt het toch wel handwerk. Al ben ik op iets aan het broeden om dat
binnen JOSM te automatiseren.

Ik heb al een Pythonscript gemaakt dat meteen ook zorgt voor het
aanmaken van associatedStreetrelaties bij het omzetten van SHP naar OSM.
De data voor Brussel is ook vrijgegeven en dat had ik daarvoor gemaakt,
maar het kan gemakkelijk aangepast worden aan de tags die in de BAG
gebruikt worden.

Jo


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






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







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

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

[Maarten Deen]

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/BAG en 
http://wiki.openstreetmap.org/wiki/BAGimport zijn 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-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] BAG gegevens Re: OSM Navigatieapparatuur

[Gertjan Idema]

Mijn werk aan de import van BAG data staat inderdaad op een wat lager
pitje. Dat komt deels door minder tijd en ook doordat ik me de laatste
tijd wat minder goed kan concentreren.

Het gemis aan adresgegevens in OSM duikt wel steeds vaker op in
discussies.
Misschien moeten we toch eens overwegen om eenmalig een import van
adressen uit de BAG (panden is een ander v verhaal) uit te voeren en
tijdelijk voor lief te nemen dat er soms dubbele adressen in de database
staan.
Daarna kunnen we scripts gebruiken om dubbelen en andere onvolkomenheden
op te sporen en te corrigeren. En ook om nieuwe adressen (en panden) toe
te voegen.

Nadelen van deze methode:
- Routeringsalgorithmen  kunnen soms moeite hebben met dubbele adressen.
- Het kan er rommelig uitzien in de huidige rendering:
http://www.openstreetmap.org/?lat=52.08095lon=5.124964zoom=18layers=M

Gertjan

On Wed, 2013-05-29 at 09:41 +0200, Minko wrote:

 Gertjan Idema was bezig met een script om de BAG data eenvoudig te kunnen 
 importeren in JOSM.
 Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er ook mee 
 bezig, maar het project staat een beetje op een laag pitje: 
 http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687
  
  De gegevens moeten wel in OSM zitten willen andere kaartgebruikers er
  voordeel van hebben.
 
 Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar achteraf 
 gemixed met de OSM data tbv onze Garmin kaarten. Het is wel beter om het in 
 OSM te voeren zodat de straatnamen van het BAG beter gematched kunnen worden 
 met die in OSM.
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://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] BAG gegevens Re: OSM Navigatieapparatuur

[Maarten Deen]

On 2013-05-29 11:21, Gertjan Idema wrote:

Mijn werk aan de import van BAG data staat inderdaad op een wat lager
pitje. Dat komt deels door minder tijd en ook doordat ik me de laatste
tijd wat minder goed kan concentreren.

 Het gemis aan adresgegevens in OSM duikt wel steeds vaker op in 
discussies.

 Misschien moeten we toch eens overwegen om eenmalig een import van
adressen uit de BAG (panden is een ander v verhaal) uit te voeren en
tijdelijk voor lief te nemen dat er soms dubbele adressen in de
database staan.
 Daarna kunnen we scripts gebruiken om dubbelen en andere
onvolkomenheden op te sporen en te corrigeren. En ook om nieuwe
adressen (en panden) toe te voegen.


Ik ben niet direkt een tegenstander van een automatische import (het 
geeft natuurlijk lekker snel resultaat) maar ik ben er wel voorstander 
van om het goed te doen. En daarmee bedoel ik dus de bestaande gebouwen 
opdelen in de afzonderlijke gebouwen en de huisnummers in de area van 
het gebouw te zetten i.p.v. afzonderlijke nodes met huisnummers neer te 
zetten.

Vergelijk waar ik in mijn woonplaats mee bezig ben:
http://www.openstreetmap.org/?lat=51.318867lon=5.995507zoom=18layers=M

Is het mogelijk iets te maken voor mijn gemeente (OSM file of wat dan 
ook) waar ik min of meer de data van kan overtrekken? Veel anders dan 
hoe ik het nu doe (met huisnummers die ik opschrijf als ik er langs 
loop) kan het niet zijn. Het scheelt me tenminste wel de tijd die ik 
moet besteden aan alle huisnummers langslopen.


Maarten


 On Wed, 2013-05-29 at 09:41 +0200, Minko wrote:

Gertjan Idema was bezig met een script om de BAG data eenvoudig te 
kunnen importeren in JOSM.
Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er 
ook mee bezig, maar het project staat een beetje op een laag pitje: 
http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687 [1]


De gegevens moeten wel in OSM zitten willen andere kaartgebruikers 
er

voordeel van hebben.


Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar 
achteraf gemixed met de OSM data tbv onze Garmin kaarten. Het is wel 
beter om het in OSM te voeren zodat de straatnamen van het BAG beter 
gematched kunnen worden met die in OSM.



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

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

[Gertjan Idema]

On Wed, 2013-05-29 at 11:54 +0200, Maarten Deen wrote:

 On 2013-05-29 11:21, Gertjan Idema wrote:
  Mijn werk aan de import van BAG data staat inderdaad op een wat lager
  pitje. Dat komt deels door minder tijd en ook doordat ik me de laatste
  tijd wat minder goed kan concentreren.
  
   Het gemis aan adresgegevens in OSM duikt wel steeds vaker op in 
  discussies.
   Misschien moeten we toch eens overwegen om eenmalig een import van
  adressen uit de BAG (panden is een ander v verhaal) uit te voeren en
  tijdelijk voor lief te nemen dat er soms dubbele adressen in de
  database staan.
   Daarna kunnen we scripts gebruiken om dubbelen en andere
  onvolkomenheden op te sporen en te corrigeren. En ook om nieuwe
  adressen (en panden) toe te voegen.
 
 Ik ben niet direkt een tegenstander van een automatische import (het 
 geeft natuurlijk lekker snel resultaat) maar ik ben er wel voorstander 
 van om het goed te doen. En daarmee bedoel ik dus de bestaande gebouwen 
 opdelen in de afzonderlijke gebouwen en de huisnummers in de area van 
 het gebouw te zetten i.p.v. afzonderlijke nodes met huisnummers neer te 
 zetten.
 Vergelijk waar ik in mijn woonplaats mee bezig ben:
 http://www.openstreetmap.org/?lat=51.318867lon=5.995507zoom=18layers=M


Ik denk dat er meerdere wensen zijn:
Er is de wens om de woonblokken uit de 3d shapes import op te splitsen
in individuele panden.
Er is de wens om OSM te voorzien van adressen ten bate van
routeplanners.
Er is de wens om daar waar mogelijk de adressen aan de panden te knopen.
Er is de wens in de toekomst wijzigingen in panden en adressen te kunnen
bijwerken OSM.
etc.

Ik vraag mij af of het allemaal in een keer moet, of dat het ook in
stappen kan. Op het moment dat je adressen zoveel mogelijk aan panden
wilt knopen, is het nodig om panden en adressen tegelijk in te voeren.
Omdat panden complexer zijn dan adressen (automatische import eigenlijk
niet mogelijk), betekent dat dat het nog lang kan duren voordat de
database voorzien is van alle adressen in Nederland.
In mijn ogen zijn de adressen waardevoller dan de panden. De
aanwezigheid van alle Nederlandse adressen in OSM biedt namelijk
mogelijkheden bieden voor allerlei op OSM gebaseerde applicaties. Dit
kan voor veel applicaties de overstap van Google naar OSM betekenen, OSM
in Nederland figuurlijk op de kaart zetten en daarmee ook weer nieuwe
vrijwilligers trekken.
Daarnaast staat in mijn ogen een  initiële import van alleen adressen
uit BAG de overige wensen niet in de weg. Als in een later stadium
individuele panden worden toegevoegd, kunnen de adressen alsnog worden
overgezet van een losse node naar een pand. Die voorziening staat al op
mijn wensenlijstje voor de Josm plug-in die ik aan het schrijven ben.

Een heel goed voorbeeld dat het niet altijd mogelijk is om adressen aan
panden te knopen zie je bij Passage de Pit in Panningen. Dit is één
gebouw met de volgende adressen:
Raadhuisstraat 4-86 (5981BG)
Markt 30-44 (5981AP)
Raadhuisplein 2-4 (5981AT)
Passage de Pit 2-7 (5981CS)

(Zie ook de BAG viewer: pdok.nl/bagviewer)




 Is het mogelijk iets te maken voor mijn gemeente (OSM file of wat dan 
 ook) waar ik min of meer de data van kan overtrekken? Veel anders dan 
 hoe ik het nu doe (met huisnummers die ik opschrijf als ik er langs 
 loop) kan het niet zijn. Het scheelt me tenminste wel de tijd die ik 
 moet besteden aan alle huisnummers langslopen.

Wel minder goed voor je conditie ;-), maar ten eerste kan je de
huisnummers van de BAG viewer halen (zie link hierboven).
Daarnaast heb ik zelf een tool waarmee ik BAG data uit een lokale
database kan omzetten naar een OSM bestand.
Ik zal je bestanden voor Panningen en Helden opsturen.

Gertjan

P.S. Staat Helden echt zo vol met hekjes?


 
 Maarten
 
   On Wed, 2013-05-29 at 09:41 +0200, Minko wrote:
  
  Gertjan Idema was bezig met een script om de BAG data eenvoudig te 
  kunnen importeren in JOSM.
  Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er 
  ook mee bezig, maar het project staat een beetje op een laag pitje: 
  http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687 [1]
  
  De gegevens moeten wel in OSM zitten willen andere kaartgebruikers 
  er
  voordeel van hebben.
  
  Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar 
  achteraf gemixed met de OSM data tbv onze Garmin kaarten. Het is wel 
  beter om het in OSM te voeren zodat de straatnamen van het BAG beter 
  gematched kunnen worden met die in OSM.
 
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://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] BAG gegevens Re: OSM Navigatieapparatuur

[Jo]

Ik kan niet beloven dat ik er tijd voor heb (ben al wat teveel hooi op m'n
vork aan het nemen), maar ik zou hier wel eens naar willen kijken.

Waar kan ik de adresgegevens voor 1 gemeente afhalen als SHP of WFS? Of
staan ze in een ander formaat?

De gebouwen zitten al in OSM, vermoed ik?

Polyglot

Op 29 mei 2013 11:21 schreef Gertjan Idema g.id...@zonnet.nl het volgende:

 **
 Mijn werk aan de import van BAG data staat inderdaad op een wat lager
 pitje. Dat komt deels door minder tijd en ook doordat ik me de laatste tijd
 wat minder goed kan concentreren.

 Het gemis aan adresgegevens in OSM duikt wel steeds vaker op in discussies.
 Misschien moeten we toch eens overwegen om eenmalig een import van
 adressen uit de BAG (panden is een ander v verhaal) uit te voeren en
 tijdelijk voor lief te nemen dat er soms dubbele adressen in de database
 staan.
 Daarna kunnen we scripts gebruiken om dubbelen en andere onvolkomenheden
 op te sporen en te corrigeren. En ook om nieuwe adressen (en panden) toe te
 voegen.

 Nadelen van deze methode:
 - Routeringsalgorithmen  kunnen soms moeite hebben met dubbele adressen.
 - Het kan er rommelig uitzien in de huidige rendering:
 http://www.openstreetmap.org/?lat=52.08095lon=5.124964zoom=18layers=M

 Gertjan


 On Wed, 2013-05-29 at 09:41 +0200, Minko wrote:

 Gertjan Idema was bezig met een script om de BAG data eenvoudig te kunnen 
 importeren in JOSM.
 Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er ook mee 
 bezig, maar het project staat een beetje op een laag pitje: 
 http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687

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

 Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar achteraf 
 gemixed met de OSM data tbv onze Garmin kaarten. Het is wel beter om het in 
 OSM te voeren zodat de straatnamen van het BAG beter gematched kunnen worden 
 met die in OSM.

 ___
 Talk-nl mailing 
 listTalk-nl@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-nl



 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://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] BAG gegevens Re: OSM Navigatieapparatuur

[Maarten Deen]

On 2013-05-29 14:05, Gertjan Idema wrote:

On Wed, 2013-05-29 at 11:54 +0200, Maarten Deen wrote:



 Een heel goed voorbeeld dat het niet altijd mogelijk is om adressen
aan panden te knopen zie je bij Passage de Pit in Panningen. Dit is
één gebouw met de volgende adressen:
 Raadhuisstraat 4-86 (5981BG)
 Markt 30-44 (5981AP)
 Raadhuisplein 2-4 (5981AT)
 Passage de Pit 2-7 (5981CS)


Dat soort dingen zul je inderdaad altijd hebben bij hoekhuizen en 
etagewoningen.
Ik zie wel dat de BAG een voorkomend probleem oplost: waar moet je bij 
flatgebouwen de huisnummers taggen: op de fysieke locatie of bij de 
(communale) ingang? De BAG doet het dus bij de ingang. Ik zal eens 
kijken of dat de enige ingang daar is, ik dacht dat er nog een was.


Maar die site van die bagviewer is ook een goede. Daar kun je ook veel 
mee (als in: gewoon overtrekken).



Is het mogelijk iets te maken voor mijn gemeente (OSM file of wat dan
ook) waar ik min of meer de data van kan overtrekken? Veel anders 
dan

hoe ik het nu doe (met huisnummers die ik opschrijf als ik er langs
loop) kan het niet zijn. Het scheelt me tenminste wel de tijd die ik
moet besteden aan alle huisnummers langslopen.

 Wel minder goed voor je conditie ;-), maar ten eerste kan je de
huisnummers van de BAG viewer halen (zie link hierboven).
 Daarnaast heb ik zelf een tool waarmee ik BAG data uit een lokale
database kan omzetten naar een OSM bestand.
 Ik zal je bestanden voor Panningen en Helden opsturen.


Bedankt daarvoor.


 P.S. Staat Helden echt zo vol met hekjes?


Voorbeeld? Bedoel je misschien de erfafscheidingen die ik op sommige 
plaatsen heb ingetekend? Ik weet ook niet of dat zo'n goed idee was 
(alhoewel dat in achtertuinen wel altijd hekken of hagen zijn).


Maarten

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

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

[Gertjan Idema]

On Wed, 2013-05-29 at 14:26 +0200, Jo wrote:

 Ik kan niet beloven dat ik er tijd voor heb (ben al wat teveel hooi op
 m'n vork aan het nemen), maar ik zou hier wel eens naar willen kijken.

Als je mee wilt denken graag.

 Waar kan ik de adresgegevens voor 1 gemeente afhalen als SHP of WFS?
 Of staan ze in een ander formaat?
 

De URL van de WFS server is
http://geodata.nationaalgeoregister.nl/bagviewer/wfs
De feature voor de adressen is 'verblijfsobject'

Met feature 'woonplaats' kan je eventueel een polygoon van een
woonplaats opvragen 



 De gebouwen zitten al in OSM, vermoed ik?


De BAG gebouwen zitten nog niet in OSM. Wat er nu in OSM zit zijn
huizenblokken uit de 3dshapes import. Deze zijn minder gedetailleerd.


 
 Polyglot
 
 
 Op 29 mei 2013 11:21 schreef Gertjan Idema g.id...@zonnet.nl het
 volgende:
 
 Mijn werk aan de import van BAG data staat inderdaad op een
 wat lager pitje. Dat komt deels door minder tijd en ook
 doordat ik me de laatste tijd wat minder goed kan
 concentreren.
 
 Het gemis aan adresgegevens in OSM duikt wel steeds vaker op
 in discussies.
 Misschien moeten we toch eens overwegen om eenmalig een import
 van adressen uit de BAG (panden is een ander v verhaal) uit te
 voeren en tijdelijk voor lief te nemen dat er soms dubbele
 adressen in de database staan.
 Daarna kunnen we scripts gebruiken om dubbelen en andere
 onvolkomenheden op te sporen en te corrigeren. En ook om
 nieuwe adressen (en panden) toe te voegen.
 
 Nadelen van deze methode:
 - Routeringsalgorithmen  kunnen soms moeite hebben met dubbele
 adressen.
 - Het kan er rommelig uitzien in de huidige rendering:
 
 http://www.openstreetmap.org/?lat=52.08095lon=5.124964zoom=18layers=M
 
 Gertjan
 
 
 
 On Wed, 2013-05-29 at 09:41 +0200, Minko wrote: 
 
  Gertjan Idema was bezig met een script om de BAG data eenvoudig te 
 kunnen importeren in JOSM.
  Ik weet niet hoever het daarmee staat. Op het OSM forum zijn we er 
 ook mee bezig, maar het project staat een beetje op een laag pitje: 
 http://forum.openstreetmap.org/viewtopic.php?pid=336687#p336687
   
   De gegevens moeten wel in OSM zitten willen andere 
 kaartgebruikers er
   voordeel van hebben.
  
  Omdat er weinig schot in de zaak zit hebben we de BAG gegevens maar 
 achteraf gemixed met de OSM data tbv onze Garmin kaarten. Het is wel beter om 
 het in OSM te voeren zodat de straatnamen van het BAG beter gematched kunnen 
 worden met die in OSM.
  
  ___
  Talk-nl mailing list
  Talk-nl@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-nl
 
 
 
 
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-nl
 
 
 
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://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] BAG gegevens Re: OSM Navigatieapparatuur

[Gertjan Idema]

On Wed, 2013-05-29 at 14:29 +0200, Maarten Deen wrote:

 On 2013-05-29 14:05, Gertjan Idema wrote:
  On Wed, 2013-05-29 at 11:54 +0200, Maarten Deen wrote:
 
   Een heel goed voorbeeld dat het niet altijd mogelijk is om adressen
  aan panden te knopen zie je bij Passage de Pit in Panningen. Dit is
  één gebouw met de volgende adressen:
   Raadhuisstraat 4-86 (5981BG)
   Markt 30-44 (5981AP)
   Raadhuisplein 2-4 (5981AT)
   Passage de Pit 2-7 (5981CS)
 
 Dat soort dingen zul je inderdaad altijd hebben bij hoekhuizen en 
 etagewoningen.
 Ik zie wel dat de BAG een voorkomend probleem oplost: waar moet je bij 
 flatgebouwen de huisnummers taggen: op de fysieke locatie of bij de 
 (communale) ingang? De BAG doet het dus bij de ingang. Ik zal eens 
 kijken of dat de enige ingang daar is, ik dacht dat er nog een was.

Dat wisselt per gemeente. BAG stelt alleen dat de huisnummers binnen de
contouren van het pand moeten liggen.
Hier kan je zien dat dat ruim geïnterpreteerd wordt:
http://www.openstreetmap.org/?lat=52.08095lon=5.124964zoom=18layers=M



 Maar die site van die bagviewer is ook een goede. Daar kun je ook veel 
 mee (als in: gewoon overtrekken).
 
  Is het mogelijk iets te maken voor mijn gemeente (OSM file of wat dan
  ook) waar ik min of meer de data van kan overtrekken? Veel anders 
  dan
  hoe ik het nu doe (met huisnummers die ik opschrijf als ik er langs
  loop) kan het niet zijn. Het scheelt me tenminste wel de tijd die ik
  moet besteden aan alle huisnummers langslopen.
   Wel minder goed voor je conditie ;-), maar ten eerste kan je de
  huisnummers van de BAG viewer halen (zie link hierboven).
   Daarnaast heb ik zelf een tool waarmee ik BAG data uit een lokale
  database kan omzetten naar een OSM bestand.
   Ik zal je bestanden voor Panningen en Helden opsturen.
 
 Bedankt daarvoor.

Graag gedaan

   P.S. Staat Helden echt zo vol met hekjes?
 
 Voorbeeld? Bedoel je misschien de erfafscheidingen die ik op sommige 
 plaatsen heb ingetekend? Ik weet ook niet of dat zo'n goed idee was 
 (alhoewel dat in achtertuinen wel altijd hekken of hagen zijn).

Wat ik zag was barrier:fence, ook waar het in werkelijkheid heggen zijn.
Beetje vreemd ook dat ze dwars door de huizen lopen. Op de Mapnik kaart
ziet het eruit alsof het kadastrale percelen zijn.

Gertjan

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

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

[Jo]

Op 29 mei 2013 14:45 schreef Gertjan Idema g.id...@zonnet.nl het volgende:

 **
 On Wed, 2013-05-29 at 14:26 +0200, Jo wrote:

 Ik kan niet beloven dat ik er tijd voor heb (ben al wat teveel hooi op m'n
 vork aan het nemen), maar ik zou hier wel eens naar willen kijken.

 Als je mee wilt denken graag.

  Waar kan ik de adresgegevens voor 1 gemeente afhalen als SHP of WFS? Of
 staan ze in een ander formaat?

  De URL van de WFS server is
 http://geodata.nationaalgeoregister.nl/bagviewer/wfs
 De feature voor de adressen is 'verblijfsobject'

 Met feature 'woonplaats' kan je eventueel een polygoon van een woonplaats
 opvragen


Ik heb die WFS benaderd met QGIS. Ik begrijp niet helemaal waarom ik maar 3
'kluitjes' adressen te zien krijg.

Deze opslaan als SHP is geen probleem. Dat SHP bestand openen in JOSM gaat
ook probleemloos. Dan alles selecteren en wat tags weggooien en andere
volgens de OSM-conventies zetten.

OK, dat was het gemakkelijkste gedeelte...



 De gebouwen zitten al in OSM, vermoed ik?


De BAG gebouwen zitten nog niet in OSM. Wat er nu in OSM zit zijn
 huizenblokken uit de 3dshapes import. Deze zijn minder gedetailleerd.


Als die gewoon weg mogen, zou het ook nog relatief eenvoudig moeten zijn om
die data over te brengen. Als de historiek best behouden blijft, wordt het
toch wel handwerk. Al ben ik op iets aan het broeden om dat binnen JOSM te
automatiseren.

Ik heb al een Pythonscript gemaakt dat meteen ook zorgt voor het aanmaken
van associatedStreetrelaties bij het omzetten van SHP naar OSM. De data
voor Brussel is ook vrijgegeven en dat had ik daarvoor gemaakt, maar het
kan gemakkelijk aangepast worden aan de tags die in de BAG gebruikt worden.

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

Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Frank Steggink]

On 21-10-2012 16:04, Sebastiaan Couwenberg wrote:
Nu de discussies over het importeren van BAG data goed op gang komen 
heb ik eens gekeken hoe hiervoor rekening te houden met de Import 
Guidelines [1]. We zijn al een heel eind op weg wat dat betreft, maar 
nog niet aan alle details is al invulling gegeven.


[1] http://wiki.openstreetmap.org/wiki/Import/Guidelines

De checklist noemt acht punten om rekening mee te houden.

1.  Gain familiarity with the basics of OpenStreetMap, including 
editing, such as adding details of your neighbourhood. Consider 
following the beginners' guide.


Ieder van ons voldoet aan dit criterium. Het is inderdaad niet 
verstandig als nieuwe mappers direct aan de slag gaan met BAG data 
voordat we hier een beginners vriendelijke handleiding voor hebben 
opgesteld.


2.  Contact the relevant local OSM community to make sure you're not 
heading down a path someone else has tried and to get a sense of how 
receptive the community is to imports. Check for local user groups, 
local chapters, and country-specific mailing lists.


De discussies met de lokale community zijn gestart op de mailinglist 
[2] en forum [3], en de reacties tot nu zijn nog niet echt negatief. 
Ik verwacht geen bezwaar van de NL community tegen de BAG imports 
zolang de uitvoering hiervan geen problemen gaat verzorgen. Zolang de 
BAG panden maar geen custom edits verwijderen, en BAG woonplaats 
grenzen de bestaanden kunnen aanpassen ipv vervangen lijkt mij de weg 
vrij. Maar het is ook nog wat vroeg om over duidelijke consensus te 
spreken. Nog niet veel verschillende mensen hebben zich in de 
discussies gemengd. Veel meer mensen verwacht eerlijk gezegd ook niet 
echt, er zijn niet erg veel NL mappers die zich ook nog eens met de 
community communicatie bezig houden lijkt het.


[2] 
http://lists.openstreetmap.org/pipermail/talk-nl/2012-October/014215.html

[3] http://forum.openstreetmap.org/viewtopic.php?id=18311

3.  Check the license of the data. If the license of the data is not 
compatible with the OpenStreetMap license, you can not use the data.


De open data portal van de Nederlandse overheid [4] is heel expliet in 
de vrije licensering van de BAG data. Licentie: Publiek Domein.


[4] 
https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag-


Op de home page van de open data portal staat dit wat uitgebreider:
http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html
Wat is open data?

 *  De data is openbaar;
 *  Er berust geen auteursrecht of andere rechten van derden op;
 *  De data zijn bekostigd uit publieke middelen, beschikbaar gesteld
voor de uitvoering van die taak;
 *  De data voldoen bij voorkeur aan ‘open standaarden’ (geen barrières
voor het gebruik door ICT-gebruikers of door ICT-aanbieders);
 *  Open Data is bij voorkeur computer-leesbaar, zodat zoekmachines
informatie in documenten kunnen vinden.

De situatie rond de postcode is mogelijk nog wel een struikelblok. 
Ondank dat de overheid de data vrij geeft, procederen PostNL en 
Cendris nog steeds tegen het vrij geven van de postcode database. Zie 
de dreigbrief tegen postcodeatlas.nl:


http://www.postcodeatlas.nl/pages/postcodebestand.html

In het vonnis van 21 december 2011 [5] word gesteld dat de postcodes 
die de overheid van PostNL krijgt niet uit het postcodebestand van 
PostNL noch de postcodetabel van Cendris komen, en de databaserechten 
die beide partijen hebben niet van toepassing zijn op de postcodes in 
de BAG. Dat na de privatisering van de PTT het toewijzen van postcodes 
niet meer door een overheidsinstantie gedaan word maakt het tot een 
vreemde situatie. Alle drie partijen stellen nu hun eigen database op 
met de gegevens die zijn gezamenlijk vast stellen zoals ze dat vroeger 
als staatsbedrijf onder een dak deden. De BAG database van de overheid 
word duidelijk als losstaand werk gezien, wat geen afgeleide is van de 
postcode databases van PostNL en Cendris.


Het vonnis word nader toegelicht in Jurispundentie Nr 1 [6].

[5] http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BU9147
[6] http://www.ivir.nl/publicaties/eechoud/Annotatie_Mf_2012_4.pdf

Mocht in het beroep dat PostNL heeft aangetekend tegen dit vonnis 
geoordeeld worden dat PostNL toch rechten heeft op de postcodes in de 
BAG, dan verwacht ik dat de overheid licentiegelden aan PostNL zal 
gaan betalen voor het gebruik van de postcodes. Wat OSM betreft zullen 
we de postcodes dan mogelijk achterwege moeten laten bij het 
importeren indien de postcodes uit de BAG niet vrijelijk gebruikt 
mogen worden. Ik kan alleen geen informatie vinden over het beroep wat 
PostNL tegen het vonnis zou hebben aangetekend.


Heeft iemand meer informatie over de huidige stand van zake in deze zaak?

4.  Find out what data layers the organization offers. This might be 
street centerlines, building outlines, waterways, addresses, etc.


Gebouwen, adressen en administratieve grenzen. Binnen de BAG bekend 
als de PND, NUM en WPL data 

Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Cartinus]

On 10/21/2012 04:04 PM, Sebastiaan Couwenberg wrote:
 Nu de discussies over het importeren van BAG data goed op gang komen heb
 ik eens gekeken hoe hiervoor rekening te houden met de Import Guidelines

snip


 We hebben nu toegang tot de meest authoratieve bron voor deze grenzen,
 waardoor ik geen bezwaar verwacht tegen het gebruik hiervan. Maar
 natuurlijk onder voorwaarde dat dit zorgvuldig gebeurt. Het is erg
 makkelijk om aangrenzende boundaries incompleet te maken bij het
 splitsen van gemeente grenzen ten behoeve van de woonplaats grenzen daarin.

De gebouwen kunnen goed in kleine hapjes worden geïmporteerd. Voor de
woonplaatsgrenzen is dat denk ik echter vragen om problemen, die zijn
veel te veel verweven met elkaar.

 Voor het opnemen van de grenzen moeten we denk ik ook een officiele
 procedure ontwikkelen al dan niet geautomatiseerd. Ik meen dat de Deense
 community een bot heeft draaien die de grenzen daar automatisch
 corrigeert met de meest recente overheids data, zoiets wil ik voor
 Nederland ook. Maar tools die het makkelijk maken om de grenzen in OSM
 op te nemen zonder andere boundaries te slopen vind ik ook wel een goed
 idee. Ik denk dat de woonplaats export de ways vast moet splitsen op de
 punten waar grenzen bij elkaar komen om het eenvoudiger in OSM op te
 nemen. Dit kan in de osmosis plugin, of ik kan daar een script voor
 schrijven om mee te beginnen.

Waarom het wiel opnieuw uitvinden? ogr2osm is voor zover ik weet
speciaal ontwikkeld voor het importeren (als multipolygonen) van
aansluitende vlakken.

- - - - - - - -

De rest van het verhaal klinkt goed.


-- 
---
m.v.g.,
Cartinus

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

Re: [OSM-talk-nl] BAG-update: ook bruikbaar voor BRT?

[Robert Elsenaar]

Mergen en een data set van maken. Dat is toch hetzelfde. Probleem is echter 
dat het geautomatiseerd samenvoegen om technische en wenselijke redenen vaak 
een probleem is en dat menselijke tussenkomst onvermijdelijk is gebleken. 
Centraal beschikbaar stellen en de community het werk laten doen (of niet) is 
precies waardoor we OSM waarderen en juist dit is de kracht van OSM. En 
kennelijk waarderen steeds meer partijen deze aanpak. 

Met vriendelijke groeten,
Robert Elsenaar 
(Verzonden vanaf Mobile)

Stefan de Konink ste...@konink.de schreef:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 03-11-11 23:08, Frank Steggink schreef:
 Zomaar een ideetje op de late avond ;)

Gegeven dat al die data PD is waarom zou je in vredesnaam meerdere
databronnen gaan mergen? In plaats van kijken hoeveel PD data nu naar
buiten komt, daar een nieuwe gecombineerde dataset van maken, en daar
een best of both worlds van maken?


Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6zGvoACgkQYH1+F2Rqwn1DNwCeIZ8ggL6/71wIaM9SmiCVJp+P
orAAnRMgTah+949vWPHFL+4MFbzLwhPP
=UmZe
-END PGP SIGNATURE-

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://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] BAG viewer

[Frank Steggink]

Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet  
om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan  
ook helemeal niet.


De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat  
authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is  
geen mogelijkheid om OSM op de een of andere manier op de Landelijke  
Voorziening aan te sluiten, om de BAG van extra attributen te  
voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te  
onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel  
twijfels over het databankenrecht, maar dat is een andere discussie.)


Quoting Stefan de Konink ste...@konink.de:


Op 02-11-11 21:02, Oliver Heesakkers schreef:

OSM is echter veel laagdrempeliger.


Onzin, als OSM laagdrempelig was kwamen er niet tal van mensen naar
mij toe met de vraag hoe ze uberhaupt data uit OSM kunnen halen.
Vector data ja, dat ze kunnen verwerken in met software. OSM XML !=
Standaard.

Er staat laagdrempelig_er_. Ik zie ook niet een leek zomaar met GML  
data in de weer gaan.



Geimporteerde BAG-data geeft de mapper gelegenheid om namen,
ingangen, openingstijden, etc. toe te voegen en geeft die mapper
ook makkelijk de gelegenheid om de plaatsing van wegen te
orienteren aan de gebouwen.


Een GML bestand geeft diezelfde functionaliteit. Ik mis het punt.

Omdat die tags niet in IMGeo (het uitwisselingsformaat voor BAG)  
gedefinieerd staan?



De huisnummers (en binnenkort wellicht postcodes) die BAG levert
zijn relevante en goed bruikbare data die ook juist voor afgeleide
 (navigatie)producten juist heel interessant zijn. Het bij elkaar
houden van de data voorkomt dan licentievraagstukken en
compatibiliteitsproblemen.


Het introduceert alleen maar licentie vraagstukken. De vraag: waarom
BAG data geedit door OSM'ers opeens niet meer PD zijn bijvoorbeeld.

De OSM-licentie blijft gelden (be it CC-BY-SA 2.0 of ODbL). Alles wat  
in OSM zit, voldoet hieraan. Er is geen enkel bezwaar om PD data te  
importeren. Afgeleide data hoeft, per definitie, niet PD te blijven.  
De originele bron blijft dat natuurlijk wel. Anders zou daar een  
share-alike clausule aanhangen.


Frank


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

Re: [OSM-talk-nl] BAG viewer

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 03-11-11 08:40, Frank Steggink schreef:
 Stefan, Oliver heeft het over het importeren van BAG-data in OSM,
 niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden.
 Dit kan ook helemeal niet.
 
 De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat 
 authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is
 geen mogelijkheid om OSM op de een of andere manier op de
 Landelijke Voorziening aan te sluiten, om de BAG van extra
 attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit
 de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft
 heb ik wel twijfels over het databankenrecht, maar dat is een
 andere discussie.)

Zover ik heb begrepen kan er bij iedere bronhouder worden
gerapporteerd als er dingen in de BAG niet kloppen.

Databankenrecht waarop? BAG licentie gelezen?


Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6yguUACgkQYH1+F2Rqwn0k2gCghHZFOpkzda0yWp0krAaKuFe1
Ez8An3nEC2rgdIrFZFJeVvyaHES98dpZ
=DA39
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Frank Steggink]

Quoting Stefan de Konink ste...@konink.de:


Op 03-11-11 08:40, Frank Steggink schreef:

Stefan, Oliver heeft het over het importeren van BAG-data in OSM,
niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden.
Dit kan ook helemeal niet.

De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat
authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is
geen mogelijkheid om OSM op de een of andere manier op de
Landelijke Voorziening aan te sluiten, om de BAG van extra
attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit
de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft
heb ik wel twijfels over het databankenrecht, maar dat is een
andere discussie.)


Zover ik heb begrepen kan er bij iedere bronhouder worden
gerapporteerd als er dingen in de BAG niet kloppen.


Succes als je deze weg wilt bewandelen :)



Databankenrecht waarop? BAG licentie gelezen?


Niet recent, dus het is me ontgaan. Google brengt me wel op deze site  
uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting  
waar naar verwezen wordt laat het databankenrecht nog als open punt  
(onverlet het auteursrecht).


Frank

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

Re: [OSM-talk-nl] BAG viewer

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 03-11-11 14:19, Frank Steggink schreef:
 Succes als je deze weg wilt bewandelen :)

Je kunt maar beter de eerste zijn he :)

Terugmelden onjuistheden BAG
Antwoord
Als u gerede twijfel heeft over de juistheid van de informatie in de
BAG, dan kunt u dit per email melden bij b...@kadaster.nl. In het
onderwerpveld van de e-mail dient u de gemeente waarbinnen het object
valt te vermelden.


Dat lijkt me nu een perfect e-mail adres om automatisch verbetering
naar toe te sturen :)


 Databankenrecht waarop? BAG licentie gelezen?
 
 Niet recent, dus het is me ontgaan. Google brengt me wel op deze
 site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's
 samenvatting waar naar verwezen wordt laat het databankenrecht nog
 als open punt (onverlet het auteursrecht).


Mag ik de BAG-data aan derden verstrekken?
Antwoord
De BAG is er voor iedereen! Hoewel de BAG in eerste instantie gebouwd
is om overheden efficiënter en klantgerichter te laten werken, is de
BAG ook beschikbaar voor burgers en bedrijven. Het beleid van de
Rijksoverheid is immers dat overheidsinformatie op een makkelijke en
goedkope wijze ter beschikking moet worden gesteld aan iedereen die
daar behoefte aan heeft.
In beginsel is er aan hergebruik van deze informatie geen belemmering
gekoppeld. Een uitzondering hierop vormt de postcode. Vanwege een oude
afspraak tussen de overheid en PostNL mag de postcode uit de BAG niet
voor commerciële doeleinden worden gebruikt. De overheid heeft deze
afspraak opgezegd en deze belemmering vervalt uiterlijk 1 februari
2012. Daarna mag, ook de postcode uit de BAG voor commerciële
doeleinden worden gebruikt, net zoals alle andere gegevens uit de BAG.


Is de FUD nu eigenlijk over?

Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6yvYwACgkQYH1+F2Rqwn1riACfXX9f/IsJBLwOw59yeTpuqcqB
/YoAn2EoPtB3ncEss3W6PiOAG0KtNXYC
=j4/p
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Frank Steggink]

On 11-11-03 05:13 PM, Stefan de Konink wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 03-11-11 14:19, Frank Steggink schreef:

Succes als je deze weg wilt bewandelen :)

Je kunt maar beter de eerste zijn he :)

Terugmelden onjuistheden BAG
Antwoord
Als u gerede twijfel heeft over de juistheid van de informatie in de
BAG, dan kunt u dit per email melden bij b...@kadaster.nl. In het
onderwerpveld van de e-mail dient u de gemeente waarbinnen het object
valt te vermelden.


Dat lijkt me nu een perfect e-mail adres om automatisch verbetering
naar toe te sturen :)



Databankenrecht waarop? BAG licentie gelezen?

Niet recent, dus het is me ontgaan. Google brengt me wel op deze
site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's
samenvatting waar naar verwezen wordt laat het databankenrecht nog
als open punt (onverlet het auteursrecht).


Mag ik de BAG-data aan derden verstrekken?
Antwoord
De BAG is er voor iedereen! Hoewel de BAG in eerste instantie gebouwd
is om overheden efficiënter en klantgerichter te laten werken, is de
BAG ook beschikbaar voor burgers en bedrijven. Het beleid van de
Rijksoverheid is immers dat overheidsinformatie op een makkelijke en
goedkope wijze ter beschikking moet worden gesteld aan iedereen die
daar behoefte aan heeft.
In beginsel is er aan hergebruik van deze informatie geen belemmering
gekoppeld. Een uitzondering hierop vormt de postcode. Vanwege een oude
afspraak tussen de overheid en PostNL mag de postcode uit de BAG niet
voor commerciële doeleinden worden gebruikt. De overheid heeft deze
afspraak opgezegd en deze belemmering vervalt uiterlijk 1 februari
2012. Daarna mag, ook de postcode uit de BAG voor commerciële
doeleinden worden gebruikt, net zoals alle andere gegevens uit de BAG.


Is de FUD nu eigenlijk over?

Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6yvYwACgkQYH1+F2Rqwn1riACfXX9f/IsJBLwOw59yeTpuqcqB
/YoAn2EoPtB3ncEss3W6PiOAG0KtNXYC
=j4/p
-END PGP SIGNATURE-

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

Volgens Google is de zin Mag ik de BAG-data aan derden verstrekken? en 
het antwoord inderdaad op de Kadaster-site te vinden (. Goed nieuws dus 
;) Alleen jammer dat hun site het net lijkt te hebben begeven, omdat ik 
een foutmelding krijg. Het zou beter zijn als het Kadaster dit op een 
zodanige plek neerzet dat het statement niet door een ASP.NET fout 
onbereikbaar wordt. Ik had dit antwoord nog niet gezien, omdat ik OSM 
minder intensief volg, maar toch de BAG-discussie interessant vind.


Ik wilde geen FUD zaaien, maar had zelf nog last van een restant 'D'. Je 
weet dat ik pro-open data ben, maar ik heb geen tijd en zin om achteraf 
met juridische zaken geconfronteerd te worden bij overhaaste beslissingen.


Frank


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

[OSM-talk-nl] BAG-update: ook bruikbaar voor BRT?

[Frank Steggink]

On 11-11-03 10:52 PM, Frank Steggink wrote:

On 11-11-03 10:37 PM, Stefan de Konink wrote:

Ik vind Franks postcode idee nog beter dan mijn woonplaats idee.


Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'.
Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere
wijziging dan 'nieuw'?

Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen 
naar de BAG-data zelf gekeken. De initiële levering is per definitie 
nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en 
einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder 
bestond, maar waarvan de eigenschappen (geometrie of attributen) 
gewijzigd zijn tussen de begin- en einddatum.


Ik neem aan dat dit in de metadata af te leiden is. NEN3610-objecten 
(dus ook BAG-objecten, want het IMGeo-model is op NEN3610 gebaseerd) 
hebben een vaststaand ID, dus de datum van laatste wijziging, of puur 
het feit dat een object in het BAG-mutatiebestand voorkomt 
(afhankelijk van de te kiezen levering) zegt genoeg.


Frank

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

Ik zat net nog te denken aan de BasisRegistratie Topografie (BRT) die 
per 1 januari a.s. gratis wordt. Dit is dus inclusief Top10NL, de 
dataset waar het PBL de 3dShapes dataset uit heeft afgeleid. Mits de BRT 
onder een gunstige licentie beschikbaar komt en mits de 3dShapes data 
zonder al te veel poespas is op te waarderen, dan zouden we hetzelfde 
proces kunnen gebruiken om de landuse data bij te werken (en andere 
Top10NL objecten toe te voegen, zoals kleine waterlopen, muren, etc.). 
De verversingscyclus zal veel onregelmatiger zijn dan bij de BAG, 
alhoewel ik niet weet wat de huidige situatie is. (Er geldt wel een 
soortgelijke terugmeldplicht als voor de BAG, dus het zou kunnen zijn 
dat updates veel continuer zijn.)


Met het opwaarderen van 3dShapes bedoel ik het volgende:
* actualiseren data (3dShapes is door de bank genomen 6 jaar oud)
* gebouwen worden niet meegenomen, want daar hebben we de BAG voor
* bijwerken / update van tags, om zo de ongelukkige categorisering van 
3dShapes te niet te doen (combinatie bos en heide - natuur), en zelfs 
gebruik maken van meer specifieke tagging (bijv. loof-/naaldbos).


De randvoorwaarden zijn als volgt:
* de geometrie moet niet al te veel afwijken, anders zouden we net zo 
goed overnieuw kunnen beginnen, maar met de opgedane ervaring raad ik 
dat niemand aan.
* de hoeveelheid werk moet in eerste instantie behapbaar zijn om de 
actualiseringsslag te doen.


Zomaar een ideetje op de late avond ;)

Groeten,

Frank


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

Re: [OSM-talk-nl] BAG-update: ook bruikbaar voor BRT?

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 03-11-11 23:08, Frank Steggink schreef:
 Zomaar een ideetje op de late avond ;)

Gegeven dat al die data PD is waarom zou je in vredesnaam meerdere
databronnen gaan mergen? In plaats van kijken hoeveel PD data nu naar
buiten komt, daar een nieuwe gecombineerde dataset van maken, en daar
een best of both worlds van maken?


Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6zGvoACgkQYH1+F2Rqwn1DNwCeIZ8ggL6/71wIaM9SmiCVJp+P
orAAnRMgTah+949vWPHFL+4MFbzLwhPP
=UmZe
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Oliver Heesakkers]

Op za 29 okt 2011 17:36:21 schreef Stefan de Konink:
 Op 29-10-11 14:50, Oliver Heesakkers schreef:
  Up-to-date houden van de data zie ik niet direct als probleem, meer
  een technische uitdaging. Bovendien moet er ook over worden
  nagedacht hoe vaak je het wilt doen (een maal per maand lijkt mij
  schromelijk overdreven).
 
 Dan denken wij daar dus duidelijk anders over. Het is totaal onnodig
 om de BAG data te importeren. Omdat de data in een PD licentie
 beschikbaar is en een open standaard gebruikt om de data te ontsluiten.
 
 Wil je de data renderen kan dat gewoon, zelfs samen met OpenStreetMap
 op 1 kaart laag.
 
 Weerleg mijn argumenten maar.

Het argument dat de data PD is leidt uberhaupt niet tot de conclusie dat het 
onnodig is om die data in de OSM-database te importeren. Je veronderstelt dat 
elke burger geen probleem zou hebben om contact op te nemen met de overheid om 
BAG-data te verwerven en ze ook kan verwerken.
OSM is echter veel laagdrempeliger.

Geimporteerde BAG-data geeft de mapper gelegenheid om namen, ingangen, 
openingstijden, etc. toe te voegen en geeft die mapper ook makkelijk de 
gelegenheid om de plaatsing van wegen te orienteren aan de gebouwen.

De huisnummers (en binnenkort wellicht postcodes) die BAG levert zijn 
relevante en goed bruikbare data die ook juist voor afgeleide 
(navigatie)producten juist heel interessant zijn. Het bij elkaar houden van de 
data voorkomt dan licentievraagstukken en compatibiliteitsproblemen.


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

Re: [OSM-talk-nl] BAG viewer

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 02-11-11 21:02, Oliver Heesakkers schreef:
 OSM is echter veel laagdrempeliger.

Onzin, als OSM laagdrempelig was kwamen er niet tal van mensen naar
mij toe met de vraag hoe ze uberhaupt data uit OSM kunnen halen.
Vector data ja, dat ze kunnen verwerken in met software. OSM XML !=
Standaard.


 Geimporteerde BAG-data geeft de mapper gelegenheid om namen,
 ingangen, openingstijden, etc. toe te voegen en geeft die mapper
 ook makkelijk de gelegenheid om de plaatsing van wegen te
 orienteren aan de gebouwen.

Een GML bestand geeft diezelfde functionaliteit. Ik mis het punt.


 De huisnummers (en binnenkort wellicht postcodes) die BAG levert
 zijn relevante en goed bruikbare data die ook juist voor afgeleide
  (navigatie)producten juist heel interessant zijn. Het bij elkaar
 houden van de data voorkomt dan licentievraagstukken en
 compatibiliteitsproblemen.

Het introduceert alleen maar licentie vraagstukken. De vraag: waarom
BAG data geedit door OSM'ers opeens niet meer PD zijn bijvoorbeeld.


Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6xvuoACgkQYH1+F2Rqwn0qUgCbBEsXSzscvFizsDyBsXYTft/T
AcQAn1+iuyAa2kx01GNJ+oaOysJC5/Ow
=gh5h
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Steven Ottens]

Hey Dick,

De BAG is heel accuraat, maar niet compleet. Het heeft een zeer duidelijk 
omschreven set van eisen en daarbinnen is het de gezaghebbende bron voor heel 
Nederland. Echter zoals elders in de discussie opgemerkt het bevat niet alles, 
zo kan een OSM gebruiker extra tags of wijzigingen op de geometrie toevoegen om 
te zeggen waar de ingang (of de rolstoel vriendelijke ingang) is, welke 
voorzieningen het pand bevat e.d.
Als een OSMer met veel zorg en liefde alle rolstoelingangen (random 
voorbeeld*)) van alle gebouwen in OSM heeft gezet, zal hij niet blij zijn als 
je blind de BAG data over zijn wijzigingen zet, met het idee dat de BAG 
gezaghebbend is. Het punt is dat de BAG gezaghebbend is in een heel specifiek 
domein, maar dat OSM over meerdere domeinen gaat (sterker nog OSM heeft 
expliciet gekozen om juist niet bij voorbaat vast te stellen welke domeinen wel 
en niet worden gemapped) en dus meer/andere informatie bevat dan de BAG.

groet
Steven

*) niet geheel random natuurlijk, ik weet uit ervaring dat er een groot 
verschil is tussen een ingang en een rolstoelvriendelijke ingang en dat een 
geometrie van een gebouw niet altijd de rolstoel-ramp toont of niet vertelt hoe 
hij loopt (boven/onder). Ik weet trouwens niet hoe de BAG dat doet.


On Oct 31, 2011, at 7:43 PM, Dick wrote:

 He Martijn,
 
 Bedankt voor je reactie.
 
 Wie weet hoe accuraat BAG is? Voor wat ik nu zie heel accuraat, wat mij 
 betreft 
 kan BAG dan blind OSM overschijven (als de data nieuwer is dan OSM en een bag 
 objekt id tag heeft).
 
 gr
 Dick
 
 
 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-nl

sudo sluiskill all


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

[OSM-talk-nl] BAG viewer

[Ruud den Blanken]

Dick d...@mrns.nlschreef:
Wie weet hoe accuraat BAG is? Voor wat ik nu zie heel accuraat, wat mij
betreft
kan BAG dan blind OSM overschijven (als de data nieuwer is dan OSM en een
bag
objekt id tag heeft).

De accuraatheid van de BAG zal per gemeente verschillen en zal afhangen van
de organisatie en de hoeveelheid aandacht die het bij een gemeente krijgt.
Bij het vervangen van de 3dShapes in Gorinchem door adressen en gebouwen
uit de BAG stuitte ik op diverse slordigheden die niet overeenstemmen met
de werkelijkheid; die zijn dan ook direct door mij aangepast.
Overall zijn vooral de gebouwcontouren stukken nauwkeuriger en recenter dan
3dShapes maar ook BAG-data is niet overal 100% foutloos.

Ik voel dan ook veel voor het idee om de BAG-data op wat voor manier dan
ook als resource ter beschikking te stellen,
en dat lokale mappers daar waar zij het belangrijk vinden de 3dShapes
vervangen door BAG-data.

Groeten,
Ruud den Blanken
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG viewer

[Cartinus]

On Sunday 30 October 2011 08:12:53 Frank Steggink wrote:
 On 11-10-30 12:52 AM, Stefan de Konink wrote:
  Dat je geen object ids nodig hebt kan kloppen als het systeem in 1
  klap alle data laat importeren en daarmee het systeem laat bij houden
  welke data is ingevoerd en welke data mapt naar welk object.

 Of je verplicht iedereen een apart importaccount aan te maken en houdt
 een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe
 vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie
 van het object (en alle nodes) nog 1 is.  Uiteraard met een
 importaccount. Het is dan wel van belang om oude data volledig te
 verwijderen en nieuwe data opnieuw te importeren, om het versienummer op
 1 te houden.

 Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op.
 Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen
 user-contributed aanvullingen weggooit.

 Het maken van een importaccount voor imports is sowieso een best
 practice! Zie
 http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a
ccount

Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata met 
data in OSM door een programma. Daar heb ik het helemaal niet over.

Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat 
buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. Dat 
geconverteerde bestand bewaar je!

De volgende keer dat je de BAG data bekijkt maak je weer een bestand in OSM 
formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met 
alleen BAG data.

De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken met 
de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee 
data-layers.

Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima te 
doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht 
bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van 
Nieuwegein is makkelijk bij te houden door één persoon.

In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan 
langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met deze 
aanpak.


-- 
m.v.g.,
Cartinus

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

Re: [OSM-talk-nl] BAG viewer

[Willem Sonke]

On 29-10-11 21:31, Stefan de Konink wrote:


Het probleem is juist het overzetten. Als ObjectIDs stabiel zijn, dan
is er geen probleem. Maar juist een systeem dat dat stukje monitort en
intelligent is om fouten op te sporen en te herstellen... dat ontbreekt.

Als het nou om data ging die 1x per jaar wordt geupdate... maar het
gaat om data die technisch gezien realtime geupdate kan worden.
Stel dat we nu al beginnen met kleinschalige imports van de BAG, dan 
wordt de kwaliteit van OSM beter in deze gebieden. Probleem is dan dat 
als OpenMetaMap of iets dergelijks klaar is, dat we dan de BAG weer uit 
OSM moeten halen en in de OMM moeten krijgen. Daarbij zou het wenselijk 
zijn om de reeds gemaakte aanpassingen door OSM'ers mee te kopiëren.


Alleen, stel dat we nu gewoon de 3dShapes laten staan. Als dan OMM klaar 
is, en we zetten de BAG daarin, hebben we dus twee verzamelingen 
gebouwen staan. Dat lijkt me ook onwenselijk en dan moeten de 
3dShapes-gebouwen dus waarschijnlijk ook weer uit OSM. Maar ook aan de 
3dShapes zijn reeds verbeteringen doorgevoerd door lokale mappers. Die 
zullen dus ook naar de OMM overgehaald moeten worden. Dan is er in feite 
toch geen verschil tussen het nu wel of niet importeren van gedeelten 
van de BAG, of begrijp ik het idee van OMM nu niet goed?


Willem Sonke

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

Re: [OSM-talk-nl] BAG viewer

[Robert Elsenaar]

Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze voor het 
importeren laagdrempelige gemaakt moet worden, zodat veel beetje ervaren lokale 
mappers het als een uitdaging zien om dit vergelijk te maken.

Groet Robert


Met vriendelijke groeten,
Robert Elsenaar 
(Verzonden vanaf Mobile)

Cartinus carti...@xs4all.nl schreef:

On Sunday 30 October 2011 08:12:53 Frank Steggink wrote:
 On 11-10-30 12:52 AM, Stefan de Konink wrote:
  Dat je geen object ids nodig hebt kan kloppen als het systeem in 1
  klap alle data laat importeren en daarmee het systeem laat bij houden
  welke data is ingevoerd en welke data mapt naar welk object.

 Of je verplicht iedereen een apart importaccount aan te maken en houdt
 een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe
 vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie
 van het object (en alle nodes) nog 1 is.  Uiteraard met een
 importaccount. Het is dan wel van belang om oude data volledig te
 verwijderen en nieuwe data opnieuw te importeren, om het versienummer op
 1 te houden.

 Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op.
 Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen
 user-contributed aanvullingen weggooit.

 Het maken van een importaccount voor imports is sowieso een best
 practice! Zie
 http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a
ccount

Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata met 
data in OSM door een programma. Daar heb ik het helemaal niet over.

Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat 
buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. Dat 
geconverteerde bestand bewaar je!

De volgende keer dat je de BAG data bekijkt maak je weer een bestand in OSM 
formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met 
alleen BAG data.

De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken met 
de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee 
data-layers.

Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima te 
doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht 
bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van 
Nieuwegein is makkelijk bij te houden door één persoon.

In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan 
langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met deze 
aanpak.


-- 
m.v.g.,
Cartinus

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://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] BAG viewer

[Frank Steggink]

On 11-10-30 10:34 AM, Robert Elsenaar wrote:
Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze 
voor het importeren laagdrempelige gemaakt moet worden, zodat veel 
beetje ervaren lokale mappers het als een uitdaging zien om dit 
vergelijk te maken.


Groet Robert


Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mobile)



Cartinus carti...@xs4all.nl schreef:


On Sunday 30 October 2011 08:12:53 Frank Steggink wrote:
 On 11-10-30 12:52 AM, Stefan de Konink wrote:
  Dat je geen object ids nodig hebt kan kloppen als het systeem in 1
  klap alle data laat importeren en daarmee het systeem laat bij houden
  welke data is ingevoerd en welke data mapt naar welk object.

 Of je verplicht iedereen een apart importaccount aan te maken en houdt
 een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe
 vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie
 van het object (en alle nodes) nog 1 is.  Uiteraard met een
 importaccount. Het is dan wel van belang om oude data volledig te
 verwijderen en nieuwe data opnieuw te importeren, om het versienummer op
 1 te houden.

 Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op.
 Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen
 user-contributed aanvullingen weggooit.

 Het maken van een importaccount voor imports is sowieso een best
 practice! Zie
 
http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a

ccount

Jullie gaan allebei nog steeds uit van vergelijken van geupdate 
brondata met

data in OSM door een programma. Daar heb ik het helemaal niet over.

Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat
buurten eromheen of je eigen dorp). Dat converteer je naar OSM 
formaat. Dat

geconverteerde bestand bewaar je!

De volgende keer dat je de BAG data bekijkt maak je weer een bestand 
in OSM

formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met
alleen BAG data.

De verschillen tussen die twee ga je vervolgens _met de hand_ 
vergelijken met

de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee
data-layers.

Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat 
prima te

doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht
bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van
Nieuwegein is makkelijk bij te houden door één persoon.

In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot 
aan
langdurig actieve mappers dat we elkaar voor de voeten zouden lopen 
met deze

aanpak.


--
m.v.g.,
Cartinus

Ik ga er niet van uit dat de vergelijking geautomatiseerd gebeurt. Ik 
beschrijf alleen hoe je de vergelijking zelf doet, niet waarmee. In JOSM 
kun je ook zoeken op version:1.
Een bepaald deel zou automatisch kunnen gebeuren (niet verplicht), maar 
het andere deel zeker niet.


Frank

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

Re: [OSM-talk-nl] BAG viewer

[Robert Elsenaar]

Ik zat zelf een beetje aan de volgende globale procedure te denken:
1) Zet de initiële brongegevens uit BAG om naar OSM formaat.
2) Open je gebied uit OSM in JOSM.
3) Leg hier overheen het zelfde gebiedje in OSM formaat dat uit de eerste 
import gemaakt is.
4) Vergelijk deze twee lagen visueel waarbij je de gebouwen uit OSM 
verwijderd die op de BAG laag beter zijn. Uiteindelijk heb je lokaal een 
projectie van de twee lagen die juist is.

5) Upload de BAG-OSM laag naar OSM.
6) Registreer de uitgevoerde update in Wiki en voeg daarbij de brongegevens 
van de gebruikte initiële update


Er zijn een aantal updates beschikbaar van de initiële BAG gegevens die je 
reeds geïmporteerd hebt.


7) Maak van de brongegevens van de updates een Delta update. Dit kan voor 
iedere lokale mapper een andere verzameling zijn omdat de één ieder kwartaal 
update en een ander ieder jaar. Ik ga uit van maandelijkse updates vanuit 
BAG.
8) Behandel deze update op gelijke manier als de initiële update en breng de 
gegevens in OSM.
9) Registreer de uitgevoerde update in Wiki en voeg daarbij de brongegevens 
van de gebruikte delta update


Ik denk dat voor het klaarmaken van de initiële update en het fabriceren van 
de delta update in OSM formaat een programma zou moeten komen die werkt 
zoals WalkingPaper (Gebied aangeven) datum laatste update opgeven en je 
kunt binnen een gepaste tijd het OSM bestand downloaden.
Verder moet er een Wiki pagina komen met de werkbeschrijving over hoe een 
update uitgevoerd kan worden inclusief tips en trucs binnen JOSM in het 
omgaan met twee layers.


Benodigdheden:
a) Centrale opslag BAG gegevens en sponsor voor het update abonnement.
b) Een programma BAG2OSM die via een pagina de updates kan aanleveren.
c) Een Wiki pagina met de beschrijving van hoe je te werk moet gaan.

Wie schiet?

groet
Robert

-Oorspronkelijk bericht- 
From: Frank Steggink

Sent: Sunday, October 30, 2011 10:44 AM
To: talk-nl@openstreetmap.org
Subject: Re: [OSM-talk-nl] BAG viewer

On 11-10-30 10:34 AM, Robert Elsenaar wrote:
Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze voor 
het importeren laagdrempelige gemaakt moet worden, zodat veel beetje 
ervaren lokale mappers het als een uitdaging zien om dit vergelijk te 
maken.


Groet Robert


Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mobile)



Cartinus carti...@xs4all.nl schreef:


On Sunday 30 October 2011 08:12:53 Frank Steggink wrote:
 On 11-10-30 12:52 AM, Stefan de Konink wrote:
  Dat je geen object ids nodig hebt kan kloppen als het systeem in 1
  klap alle data laat importeren en daarmee het systeem laat bij houden
  welke data is ingevoerd en welke data mapt naar welk object.

 Of je verplicht iedereen een apart importaccount aan te maken en houdt
 een lijst van deze accounts bij. Dan kun je de data zonder teveel gedoe
 vervangen zodra er een mutatie is gedetecteerd, maar wanneer de versie
 van het object (en alle nodes) nog 1 is.  Uiteraard met een
 importaccount. Het is dan wel van belang om oude data volledig te
 verwijderen en nieuwe data opnieuw te importeren, om het versienummer op
 1 te houden.

 Wanneer de bestaande data al gewijzigd is, dan gaat dit niet meer op.
 Dit zal handmatig moeten gebeuren, om zeker te weten dat je geen
 user-contributed aanvullingen weggooit.

 Het maken van een importaccount voor imports is sowieso een best
 practice! Zie

http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_a
ccount

Jullie gaan allebei nog steeds uit van vergelijken van geupdate brondata 
met

data in OSM door een programma. Daar heb ik het helemaal niet over.

Je neemt BAG data van een beperkt gebied (je eigen buurt en misschien wat
buurten eromheen of je eigen dorp). Dat converteer je naar OSM formaat. 
Dat

geconverteerde bestand bewaar je!

De volgende keer dat je de BAG data bekijkt maak je weer een bestand in 
OSM

formaat met alleen BAG data. Dat vergelijk je met het vorige bestand met
alleen BAG data.

De verschillen tussen die twee ga je vervolgens _met de hand_ vergelijken 
met

de data in OSM. Data vergelijken gaat bijvoorbeeld prima in JOSM met twee
data-layers.

Zolang de lokale mapper niet te veel hooi op z'n vork neemt moet dat prima 
te

doen zijn. Dus: Hé, laat ik in m'n eentje de hele provincie Utrecht
bijhouden. gaat nooit lukken. Utrecht Zuid-West en de noordrand van
Nieuwegein is makkelijk bij te houden door één persoon.

In de meeste plaatsen in Nederland hebben we niet zo'n groot overschot aan
langdurig actieve mappers dat we elkaar voor de voeten zouden lopen met 
deze

aanpak.


--
m.v.g.,
Cartinus


Ik ga er niet van uit dat de vergelijking geautomatiseerd gebeurt. Ik
beschrijf alleen hoe je de vergelijking zelf doet, niet waarmee. In JOSM
kun je ook zoeken op version:1.
Een bepaald deel zou automatisch kunnen gebeuren (niet verplicht), maar
het andere deel zeker niet.

Frank

___
Talk-nl mailing list
Talk-nl@openstreetmap.org

Re: [OSM-talk-nl] BAG viewer

[Willem Sonke]

On 30-10-11 12:58, Andre wrote:


De bestanden kunnen via 1 goedkoop abonnement van meen ik 160 euro
landelijk worden verkregen, waarom zou je dan niet landelijk
importeren? Per gemeente importeren vraagt om inconsistentie: de
actualiteit en verversingsfreqentie gaat dan per gebied afwijken en
daarmee is de kaart niet meet als referentie te gebruiken, want je
weet dan niet meer waar je naar lijkt.

Dat is nu, met de 3dShapes, ook niet het geval. Ik heb zelf het idee: 
als je exacte gebouwendata wilt, dan zul je toch naar de ruwe BAG moeten 
kijken.


Is het dan niet beter om de gehele BAG in 1 x landelijk te importeren
en dan in zijn geheel om de drie maanden te vervangen? Dus verwijderen
en opnieuw importeren. Er zullen weinig of geen mutaties nodig zijn
schat ik dan in. De huidige 3dshapes kunnen er dan uit. Blijven er dan
toch nog verschillen over, dan zouden die in een aparte laag kunnen,
die wel gemuteerd kan worden. Ik denk echter dat de meeste mutaties
dan even vooroplopen op de BAG, en na verloop van tijd wel weer eruit
kunnen. Ik denk dat de BAG alleen dan goed genoeg is. Eventueel kan de
verversings frequentue dan omhoog naar 1x per maand.

Bij iedere update van de BAG moet wel gekeken worden of er door OSM'ers 
geen updates gedaan zijn. Bij een massale landelijke import en 
landelijke updates loop je het risico dat gegevens van mensen die zelf 
veel moeite hebben gedaan ze toe te voegen zomaar verwijderd worden. Om 
dat te voorkomen moet er continu contact zijn met de lokale mappers. Dan 
kunnen die de import en updates toch net zo goed zelf doen?


De vraag is of het een probleem is dat de BAG niet letterlijk in OSM 
zit; ik vind van niet, sterker nog, ik vind het onwenselijk. De gegevens 
moeten kunnen worden aangepast, dat is juist het idee van OSM. We moeten 
dus voorkomen dat er iedere maand een landelijke update eroverheen komt 
die al je verbeteringen weer teniet doet. Ik zeg niet dat het onmogelijk 
is om landelijk goed te regelen, maar er moet wel veel aandacht aan 
worden besteed.


Daarnaast is het een idee om behalve de gebouwen ook de huisnummers
met daaraan gekoppeld de adresinformatie op te nemen in OSM op
zodanige wijze dat ook op adres gezocht kan gaan worden?

Dat lijkt me sowieso een goed idee, net zoals dat gedaan is in 
Gorinchem. Dan hebben we eindelijk fatsoenlijke deur-tot-deur-navigatie 
in heel Nederland :-)


Willem Sonke

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

Re: [OSM-talk-nl] BAG viewer

[Robert Elsenaar]

Is mijn procedure niet overgekomen? Vanmorgen gaf ik al een idee over het 
beschikbaar stellen van de laatste relevante BAG  gegevens aan lokale mappers .


Met vriendelijke groeten,
Robert Elsenaar 
(Verzonden vanaf Mobile)

Henk Hoff toffeh...@gmail.com schreef:

2011/10/30 Willem Sonke willemso...@planet.nl
Bij iedere update van de BAG moet wel gekeken worden of er door OSM'ers geen 
updates gedaan zijn. Bij een massale landelijke import en landelijke updates 
loop je het risico dat gegevens van mensen die zelf veel moeite hebben gedaan 
ze toe te voegen zomaar verwijderd worden. Om dat te voorkomen moet er continu 
contact zijn met de lokale mappers. Dan kunnen die de import en updates toch 
net zo goed zelf doen?

De vraag is of het een probleem is dat de BAG niet letterlijk in OSM zit; ik 
vind van niet, sterker nog, ik vind het onwenselijk. De gegevens moeten kunnen 
worden aangepast, dat is juist het idee van OSM. We moeten dus voorkomen dat er 
iedere maand een landelijke update eroverheen komt die al je verbeteringen weer 
teniet doet. Ik zeg niet dat het onmogelijk is om landelijk goed te regelen, 
maar er moet wel veel aandacht aan worden besteed.


In een forum op SotM Wenen werd gesteld dat imports de community om zeep 
helpen. Daar zit een kern van waarheid in. Hetgeen Willem dus ook aangeeft.
Het is uiteraard uitdagend om een kick-ass import script te schrijven die 
ervoor zorgt dat OSM-nl een kopie wordt van de BAG. Maar daarbij gaat we 
voorbij aan het idee achter OSM. Daarnaast staat door andere NL-importen in het 
recente verleden verschillende data dubbel in. Kortom, hoe kun je van bomen een 
bos maken en dat laten veranderen in een ondoordringbaar oerwoud.

Neemt niet weg dat de BAG een interessante data-source is waar we wat aan 
kunnen hebben.

Is het een idee om een mogelijkheid te hebben wanneer (middels plug-in in JOSM 
bv) om een BAG als een achtergrond te hebben vanwaar eenvoudig geselecteerde 
data van het BAG naar de OSM laag gekopieerd kan worden? Op deze wijze kan 
iedereen binnen de OSM community helpen om zijn deel van de kaart beter te 
maken.
Tegelijkertijd zit er ook een visuele check op dat er geen al te rare dingen 
wordt gedaan.

Met een beetje creativiteit kan deze tool dan ook door andere landen gebruikt 
worden. Nederland is nl niet het enige land waarin geodata wordt vrijgegeven.

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

Re: [OSM-talk-nl] BAG viewer

[Cartinus]

On Sunday 30 October 2011 19:26:09 Dick wrote:
 Dan kunnen we, als de bag data is gewijzigd
 de OSM data automatisch aanpassen.

Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is 
simpel.

Het probleem is het respecteren van andere edits op hetzelfde object. In de 
BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel 
of restaurant er zit. Of... Of...

Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen, 
maar wat een update script niet kan.

-- 
m.v.g.,
Cartinus

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

Re: [OSM-talk-nl] BAG viewer

[Jo]

Op 30 oktober 2011 19:56 heeft Cartinus carti...@xs4all.nl het
volgende geschreven:
 On Sunday 30 October 2011 19:26:09 Dick wrote:
 Dan kunnen we, als de bag data is gewijzigd
 de OSM data automatisch aanpassen.

 Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is
 simpel.

 Het probleem is het respecteren van andere edits op hetzelfde object. In de
 BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel
 of restaurant er zit. Of... Of...

 Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen,
 maar wat een update script niet kan.

De oplossing voor dit probleem zoals ik het zie, is het maken van een
script dat niet automatisch gaat updaten, maar dat een rapport
aanmaakt met aandachtspunten waar medewerkers dan mee aan de slag
kunnen om wijzigingen van upstream te gaan samenvoegen met de
bijdragen van de medewerkers. Als daar vanwege upstream interesse voor
is, kunnen bepaalde wijzigingen misschien ook teruggekoppeld worden.

Een ander probleem zijn wijzigingen die moedwillig (vandalisme) of per
ongeluk (onvervaren mapper o.i.d.) worden aangebracht. Eigenlijk
zouden we dat ook moeten kunnen detecteren.

mvg,

Jo

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

Re: [OSM-talk-nl] BAG viewer

[Martijn van Exel]

De bottleneck zit 'm in die 'medewerkers'. Wie gaat er door die
gegenereerde rapporten heenwerken? We zijn allemaal vrijwilligers
hier, met soms veel tijd maar meestal maar een klein beetje. Mensen
komen, en mensen gaan ook weer. Ik heb zelf honderden, misschien wel
duizenden building-objecten bewerkt in Nederland, maar woon nu in de
VS en richt mijn schaarse vrije tijd op het verbeteren van de kaart
hier. Zonder de continuiteit van een organisatie met vaste medewerkers
kun je geen processen gaan inrichten die voor hun voortgang
afhankelijk zijn van mensen. De geografische dimensie maakt het nog
extra lastig. Iemand die in Schagen woont kan niet zonder meer
BAG-mutaties samenvoegen met lokale OSM-mutaties in Ootmarsum, omdat
de kans heel groot is dat je lokale kennis nodig hebt om te beslissen
welke mutatie gehonoreerd moet worden in geval van conflicten.

Een dataset als de BAG, die al zo goed wordt bijgehouden (bij wet
geregeld!) door de lokale overheden, kan in de dynamiek van OSM geen
goede plek vinden en heeft er dan ook niets te zoeken.

Martijn.


2011/10/30 Jo winfi...@gmail.com:
 Op 30 oktober 2011 19:56 heeft Cartinus carti...@xs4all.nl het
 volgende geschreven:
 On Sunday 30 October 2011 19:26:09 Dick wrote:
 Dan kunnen we, als de bag data is gewijzigd
 de OSM data automatisch aanpassen.

 Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is
 simpel.

 Het probleem is het respecteren van andere edits op hetzelfde object. In de
 BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel
 of restaurant er zit. Of... Of...

 Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen,
 maar wat een update script niet kan.

 De oplossing voor dit probleem zoals ik het zie, is het maken van een
 script dat niet automatisch gaat updaten, maar dat een rapport
 aanmaakt met aandachtspunten waar medewerkers dan mee aan de slag
 kunnen om wijzigingen van upstream te gaan samenvoegen met de
 bijdragen van de medewerkers. Als daar vanwege upstream interesse voor
 is, kunnen bepaalde wijzigingen misschien ook teruggekoppeld worden.

 Een ander probleem zijn wijzigingen die moedwillig (vandalisme) of per
 ongeluk (onvervaren mapper o.i.d.) worden aangebracht. Eigenlijk
 zouden we dat ook moeten kunnen detecteren.

 mvg,

 Jo

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




-- 
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com

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

Re: [OSM-talk-nl] BAG viewer

[Robert Elsenaar]

Met vriendelijke groeten,
Robert Elsenaar 
(Verzonden vanaf Mobile)

Martijn van Exel m...@rtijn.org schreef:

De bottleneck zit 'm in die 'medewerkers'. Wie gaat er door die
gegenereerde rapporten heenwerken? We zijn allemaal vrijwilligers
hier, met soms veel tijd maar meestal maar een klein beetje. Mensen
komen, en mensen gaan ook weer. Ik heb zelf honderden, misschien wel
duizenden building-objecten bewerkt in Nederland, maar woon nu in de
VS en richt mijn schaarse vrije tijd op het verbeteren van de kaart
hier. Zonder de continuiteit van een organisatie met vaste medewerkers
kun je geen processen gaan inrichten die voor hun voortgang
afhankelijk zijn van mensen. De geografische dimensie maakt het nog
extra lastig. Iemand die in Schagen woont kan niet zonder meer
BAG-mutaties samenvoegen met lokale OSM-mutaties in Ootmarsum, omdat
de kans heel groot is dat je lokale kennis nodig hebt om te beslissen
welke mutatie gehonoreerd moet worden in geval van conflicten.

Een dataset als de BAG, die al zo goed wordt bijgehouden (bij wet
geregeld!) door de lokale overheden, kan in de dynamiek van OSM geen
goede plek vinden en heeft er dan ook niets te zoeken.

Martijn.


2011/10/30 Jo winfi...@gmail.com:
 Op 30 oktober 2011 19:56 heeft Cartinus carti...@xs4all.nl het
 volgende geschreven:
 On Sunday 30 October 2011 19:26:09 Dick wrote:
 Dan kunnen we, als de bag data is gewijzigd
 de OSM data automatisch aanpassen.

 Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is
 simpel.

 Het probleem is het respecteren van andere edits op hetzelfde object. In de
 BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel
 of restaurant er zit. Of... Of...

 Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen,
 maar wat een update script niet kan.

 De oplossing voor dit probleem zoals ik het zie, is het maken van een
 script dat niet automatisch gaat updaten, maar dat een rapport
 aanmaakt met aandachtspunten waar medewerkers dan mee aan de slag
 kunnen om wijzigingen van upstream te gaan samenvoegen met de
 bijdragen van de medewerkers. Als daar vanwege upstream interesse voor
 is, kunnen bepaalde wijzigingen misschien ook teruggekoppeld worden.

 Een ander probleem zijn wijzigingen die moedwillig (vandalisme) of per
 ongeluk (onvervaren mapper o.i.d.) worden aangebracht. Eigenlijk
 zouden we dat ook moeten kunnen detecteren.

 mvg,

 Jo

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




-- 
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://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] BAG viewer

[Oliver Heesakkers]

Op vr 28 okt 2011 13:48:00 schreef Stefan de Konink:
 Op 28-10-11 13:06, Maarten Deen schreef:
  On Fri, 28 Oct 2011 12:51:23 +0200, Just van den Broecke wrote:
  Importeren van BAG in OSM is natuurlijk een andere optie maar dat
  is een aparte discussie die elders gevoerd wordt :-).
  
  Mag dat, BAG gegevens gebruken in OSM?
 
 Ja, maar laten we vooral OSM nog een grote rotzooi maken als de mag
 maandelijks door het Kadaster wordt geupdate en er nog _nooit_ 1
 externe bron in OSM goed is gesynced.

De BAG-data is juist een opruiming. Weg met die oude schots en scheve 3dShapes 
gebouwen. Dat het in verleden nooit goed gesynced is betekent niet dat het nu 
niet zou kunnen. Alleen moeten er dan wel korte termijn spijkers met koppen 
worden geslagen. Bij gebrek aan een landelijke regie beginnen individuele 
mappers beginnen nu al individuele steden van BAG-data te voorzien. Overigens 
ben ik er ook voorstander van om de individuele mappers (evt onder 
begeleiding) in te schakelen om hun stad (en omstreken) van de BAG-import te 
voorzien en landelijk alleen een regie te voeren.

Up-to-date houden van de data zie ik niet direct als probleem, meer een 
technische uitdaging. Bovendien moet er ook over worden nagedacht hoe vaak je 
het wilt doen (een maal per maand lijkt mij schromelijk overdreven).

 Wat ik wil voorstellen is een combi-render. Zoals nu al gebeurd met de
 water/land grenzen.

Hoe bedoel je dat precies? we hebben toch admin_level=2 en 
border_type=territorial in de database zitten?

Ik blijf er bij dat de import in de OSM-database plaats moet vinden. Zoals ik 
net al schreef verspreidt deze gedacht zich ook naar andere gebruikers. Naast 
het alom bekende Nijmegen is nu ook Gorinchem voorzien van de BAG-data.
In het bijbehorende forumtopic[1] worden ook Helmond en Putten als volgende 
kandidaten genoemd en persoonlijk heb ik ook wel zin om de gemeente Eindhoven 
aan te schrijven, al was het alleen maar om de update-procedure zelf eens te 
bestuderen.

@Martijn: De laatste keer dat we hierover spraken, haalde jij de 
paneldiscussie I fight authority, Authority always wins aan op de SotM 2011 
waar jij zelf ook deel van uitmaakte.[1]
Is daar nog iets interessants/relevants voor deze discussie uitgekomen?

Oliver

[1] http://forum.openstreetmap.org/viewtopic.php?id=13917
[2] 
http://wiki.openstreetmap.org/wiki/SotM_2011_Panel:_I_fight_authority,_Authority_always_wins


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

Re: [OSM-talk-nl] BAG viewer

[Willem Sonke]

On 29-10-11 19:23, Stefan de Konink wrote:

Het heeft exact het zelfde probleem als een landelijke import, alleen
is de vervuiling lokaler. Als er regie gevoerd moet worden begin dan
gewoon goed; dat wil zeggen: implementeer openmetamap op een manier
dat het gebruikbaar is, en het geen grote geograbbelton wordt.
Ik heb even op de Wiki gekeken wat OpenMetaMap nu precies inhoudt, en 
het idee is erg goed. Ik vrees alleen dat een en ander in de praktijk 
heel lastig te implementeren is. Daardoor zal het nog wel een tijd duren 
totdat dit beschikbaar is.


Maar wat is het probleem als we in de tussentijd gecontroleerd de BAG al 
toevoegen? Op dit moment staat er 3dShapes die naar verwachting niet 
bijgewerkt gaat worden en van lagere kwaliteit is. Ik zie niet in waarom 
we niet ondertussen op kleine schaal de BAG zouden kunnen importeren. 
Als dan OpenMetaMap klaar is, dan kan alles toch nog overgezet worden?

Daarmee kunnen bronnen worden gerespecteerd, en data op een juiste
wijzen kan 'geciteerd' worden. Updates bijhouden en updates terug
laten vloeien naar gemeentes lijkt me dan erg goed. Daar is nu geen
infrastructuur voor, niet in OSM niet bij het Kadaster en al zeker
niet bij de gemeentes. Maar dit is wel de burgerparticipatie die we
nodig hebben.
Het terug laten vloeien van bijgewerkte gegevens naar de gemeenten lijkt 
me zinvol, maar ik vraag me af of de overheid daar zelf behoefte aan 
heeft. Ik denk dat ze vanwege de nauwkeurigheid alle gebouwen toch zelf 
willen opmeten -- OSM'ers zijn ten slotte geen landmeters die punten op 
de decimeter nauwkeurig kunnen inmeten.

Daarbij is het dus van belang dat als iemand in de Kadaster data edit,
hij expliciet toestemming geeft dat zijn data ook gebruikt mag worden
om verbetering door te voeren. Dat betekent weer dat daarop geen ODbL
kan zitten...
Dat weet ik niet, mijn juridische kennis is niet bepaald goed te noemen. 
:-)


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

Re: [OSM-talk-nl] BAG viewer

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 29-10-11 19:41, Willem Sonke schreef:
 Maar wat is het probleem als we in de tussentijd gecontroleerd de
 BAG al toevoegen? Op dit moment staat er 3dShapes die naar
 verwachting niet bijgewerkt gaat worden en van lagere kwaliteit is.
 Ik zie niet in waarom we niet ondertussen op kleine schaal de BAG
 zouden kunnen importeren. Als dan OpenMetaMap klaar is, dan kan
 alles toch nog overgezet worden?

Het probleem is juist het overzetten. Als ObjectIDs stabiel zijn, dan
is er geen probleem. Maar juist een systeem dat dat stukje monitort en
intelligent is om fouten op te sporen en te herstellen... dat ontbreekt.

Als het nou om data ging die 1x per jaar wordt geupdate... maar het
gaat om data die technisch gezien realtime geupdate kan worden.


 Het terug laten vloeien van bijgewerkte gegevens naar de gemeenten
 lijkt me zinvol, maar ik vraag me af of de overheid daar zelf
 behoefte aan heeft. Ik denk dat ze vanwege de nauwkeurigheid alle
 gebouwen toch zelf willen opmeten -- OSM'ers zijn ten slotte geen
 landmeters die punten op de decimeter nauwkeurig kunnen inmeten.

Als een OSM'er aangeeft: deze invloed klopt niet. Is die constatering
even waardevol als verbeterjebuurt.nl


Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6sVIMACgkQYH1+F2Rqwn3UCQCfQog56E+ewwq1wPdxEKgYjDqq
ChcAniDU+3Fa3wLnZAKjMzUnCSin8aDx
=BaT4
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Cartinus]

On Saturday 29 October 2011 19:41:03 Willem Sonke wrote:
 On 29-10-11 19:23, Stefan de Konink wrote:
  Het heeft exact het zelfde probleem als een landelijke import, alleen
  is de vervuiling lokaler. Als er regie gevoerd moet worden begin dan
  gewoon goed; dat wil zeggen: implementeer openmetamap op een manier
  dat het gebruikbaar is, en het geen grote geograbbelton wordt.

 Ik heb even op de Wiki gekeken wat OpenMetaMap nu precies inhoudt, en
 het idee is erg goed. Ik vrees alleen dat een en ander in de praktijk
 heel lastig te implementeren is. Daardoor zal het nog wel een tijd duren
 totdat dit beschikbaar is.

 Maar wat is het probleem als we in de tussentijd gecontroleerd de BAG al
 toevoegen? Op dit moment staat er 3dShapes die naar verwachting niet
 bijgewerkt gaat worden en van lagere kwaliteit is. Ik zie niet in waarom
 we niet ondertussen op kleine schaal de BAG zouden kunnen importeren.

Als OpenMetaMap ooit van vapourware verandert in realiteit zal het zeker een 
mooie tool zijn.

Tot die tijd kan het ook volgens mij geen kwaad als lokale mappers selectief 
de onnauwkeurige en/of verouderde 3dShapes vervangen door wat beters.

On Saturday 29 October 2011 21:31:15 Stefan de Konink wrote:
 Het probleem is juist het overzetten. Als ObjectIDs stabiel zijn, dan
 is er geen probleem. Maar juist een systeem dat dat stukje monitort en
 intelligent is om fouten op te sporen en te herstellen... dat ontbreekt.

Voor monitoring van veranderingen in de brondata heb je helemaal geen stabiele 
ObjectID's binnen OSM nodig. Daarvoor heb je de brondata van nu en de 
brondata zoals hij was toen je er de vorige keer naar keek nodig. Zolang een 
lokale mapper een gebied in de gaten houd dat niet al te groot is, zal het 
geen probleem zijn om die wijzigingen _met de hand_ in OSM te verwerken. 
Zoveel wordt er in Nederland nu ook weer niet ge- en verbouwd.

-- 
m.v.g.,
Cartinus

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

Re: [OSM-talk-nl] BAG viewer

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 29-10-11 23:38, Cartinus schreef:
 Zoveel wordt er in Nederland nu ook weer niet ge- en verbouwd.

...je hebt werkelijk geen idee.

Dat je geen object ids nodig hebt kan kloppen als het systeem in 1
klap alle data laat importeren en daarmee het systeem laat bij houden
welke data is ingevoerd en welke data mapt naar welk object.

Maar goed je noede het zelf net vaporware. Laten we vooral alles wat
goed beschreven is voordat het gebouwd dient te worden afschilderen
als vaporware, daar schieten we wat mee op.


Stefan

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6sg5gACgkQYH1+F2Rqwn3+qQCeIiGgFPD5DPGusVssI95SWSU4
K9YAoIQ/SI6kx3UvRPzKF6/FGxIVE7cV
=f+0z
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 28-10-11 13:06, Maarten Deen schreef:
 On Fri, 28 Oct 2011 12:51:23 +0200, Just van den Broecke wrote:
 
 Importeren van BAG in OSM is natuurlijk een andere optie maar dat
 is een aparte discussie die elders gevoerd wordt :-).
 
 Mag dat, BAG gegevens gebruken in OSM?

Ja, maar laten we vooral OSM nog een grote rotzooi maken als de mag
maandelijks door het Kadaster wordt geupdate en er nog _nooit_ 1
externe bron in OSM goed is gesynced.

Wat ik wil voorstellen is een combi-render. Zoals nu al gebeurd met de
water/land grenzen. Maar dan alle gemeente grenzen, en gebouwen uit BAG.


Ik heb voor de liefhebbers ook een aanvraag gedaan om de beide
OpenStreetMap.nl servers aan te sluiten op PDOK.nl


Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6qlnAACgkQYH1+F2Rqwn2+8gCfQQd/YJzF5lNrXaEB3xYSXz/E
kYoAnj+BrC1RaOVI5I1eWbrdRu/PxqNI
=23zK
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Stefan de Konink]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 28-10-11 14:10, Maarten Deen schreef:
 Ik heb namelijk zelf de woonplaatsgrenzen voor mijn gemeente
 ingetekend. Het is allemaal erg ruw en gebaseerd op wat ik weet en
 hoe de postcodes lopen en de BAG geeft daar een paar leuke
 verduidelijkingen. Dat kan en mag ik dus aanpassen ;-)

Pas op... fundamentele discussie...

Kadaster zou de autoriteit moeten zijn op het gebied van die data. Als
jij 'verduidelijkingen' belangrijk vindt moet er een manier zijn om
die data aan jouw gemeente te overleggen...

OpenMetaMap implementeren voor de BAG? Vrijwilligers?


 En dan ga ik ook mijn tuinhuisje intekenen :-D

;) Spielerij ;)

Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6qnikACgkQYH1+F2Rqwn0z2gCeKoKZOG3IPMKA2kegZwAmffBz
oAYAoIwYVPti+yob1YweV7oX9ny3burU
=lOcm
-END PGP SIGNATURE-

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

Re: [OSM-talk-nl] BAG viewer

[Jo]

 En dan ga ik ook mijn tuinhuisje intekenen :-D

 ;) Spielerij ;)

Als de volgende mapping party daar doorgaat, moeten we dat natuurlijk
wel weten te vinden, he. Hij moet dan wel zorgen voor Wifi, ook, vind
ik.

Jo

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

Re: [OSM-talk-nl] BAG viewer

[Robert Elsenaar]

Dat lijkt me gaaf.

Robert

-Oorspronkelijk bericht- 
From: Martijn van Exel

Sent: Friday, October 28, 2011 4:49 PM
To: OpenStreetMap NL discussion list
Subject: Re: [OSM-talk-nl] BAG viewer

Een manier is converteren naar SHP met de BAG-conversietool [1] en dan
een tiled layer aanmaken met bijv Geoserver.
Is nog steeds een hoop werk, vanwege de inmense grootte van het BAG-bestand.
Je kunt ook de tile-configuratie van de BAG viewer achterhalen en die
in JOSM prikken, denkelijk?

[1] https://github.com/MinIenM/BAG-Extract

2011/10/27 Robert Elsenaar rob...@elsenaar.info:

vertel, vertel. Hoe projrcteer ik BAG op OSM?


Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mobile)


Stefan de Konink ste...@konink.de schreef:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Op 27-10-11 21:51, Jeroen Muris schreef:

In ieder geval leuk om eens te zijn wat er nu eigenlijk in de
veelbesproken BAG zit...


Uiteraard als je de vector versie op openstreetmap wilt zien ;) Kan
dat ook wel geregeld worden.

Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6pyZcACgkQYH1+F2Rqwn3UbQCglQiNl+ngY7MWY75g9EiEDonp
MxAAn03JNZ7ZD8MZYXQ3sNBCWNZqqSPQ
=oniZ
-END PGP SIGNATURE-

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


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






--
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com

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


---
Tekst ingevoegd door Panda GP 2011:

Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende 
link om de e-mail te herclasseren: 
http://localhost:6083/Panda?ID=pav_10691SPAM=truepath=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam
--- 



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

Re: [OSM-talk-nl] BAG: woonplaatsgrenzen

[Eugene van der Pijll]

theun schreef:
Daarna heeft Eugene van der Pijll nog heel wat woonplaatsgrenzen
toegevoegd. Eugene is de laatste maanden wat stilgevallen, dus ik weet
niet of hij hier nog van plan is mee door te gaan.

Klopt, ik heb redelijk wat grenzen toegevoegd. Dat waren allemaal
gemeenten die geen GIS-bestandje met woonplaatsgrenzen hadden
opgestuurd, maar enkel een plaatje (PDF of JPEG). Die heb ik nagetekend,
om in ieder geval 99% van de adressen een juiste woonplaats te geven.

Ik ben daar om een aantal redenen mee gestopt:
- het kostte erg veel tijd;
- licentie-bezwaren (zoals Lennard al aangaf);
- er waren niet veel gemeenten meer over die een woonplaatsgrenzenkaart
  hadden opgestuurd;
- sommige kaartjes waren wel erg onduidelijk gescand;
- en iemand kondigde hier al de beschikbaarheid van de BAG aan, en daar
  bleken de grenzen ook al in te staan.

De woonplaatsgrenzen zijn echter nog niet helemaal compleet, de BAG bevat
ook alle woonplaatsgrenzen. Is het misschien een idee om in ieder geval
die te complementeren.

Ja. Je kan de door mij toegevoegde grenzen gewoon allemaal wissen, want
als het goed is zijn de grenzen uit de BAG veel beter. (Misschien wel
eerst even checken.)

Mijn grenzen zijn te herkennen aan de tag authoritative=no, die ik
geprobeerd heb om altijd toe te voegen.

Eugene

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[dbussche]

Er zijn twee belangrijke redenen voor de import:
1. internationale applicaties zoals smartphone-navigatie en b.v. 
onderzoekstoepassingen verwachten adressen en gebouwen in de dataset, niet 
apart. Niemand gaat speciaal voor Nederland andere code maken.
2. het is nutteloze bezigheidstherapie voor mappers om gebouwen en 
huisnummers in te tekenen die al lang beschikbaar zijn. Mijn tijd en 
energie wil ik liever kwijt in bijhouden van nieuwe ontwikkelingen, taggen 
van gebruik van de gebouwen etc

Wat mij betreft graag een werkgroep oprichten die in eerste instantie 2 
vragen meekrijgt:
- ontwikkel een procedure voor import en up-to-date houden van gebouwen en 
adressen uit BAG rekening houdend met edits van mappers
- ga na welke mogelijkheden de BAG-licentie biedt, hoe we praktisch bij de 
data komen

En dit dan weer hier terugkoppelt alvorens het ook daadwerkelijk te 
bouwen.

Ik wil deel van de werkgroep zijn. Wie meer?

Groeten,

   Dirk


Dirk Bussche
Senior Adviseur Geografische Toepassingen

T +31 (0)570 666 830  ▪  E dbuss...@goudappel.nl
(aanwezig op kantoor: maandag, dinsdag en woensdag)

Goudappel Coffeng  ▪  Snipperlingsdijk 4  ▪  7417 BJ Deventer  ▪ 
Postbus 161  ▪  7400 AD Deventer  ▪  The Netherlands  ▪  
www.goudappel.nl
Goudappel Coffeng BV is gevestigd in Deventer, Den Haag, Eindhoven, 
Leeuwarden en Amsterdam
__ 



  
Disclaimer  

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend 
bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u 
verzocht de inhoud niet te gebruiken en de afzender direct te informeren door 
het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die 
voortvloeit uit elektronische verzending.  
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Christ van Willegen]

Dirk,

 Wat mij betreft graag een werkgroep oprichten die in eerste instantie 2
 vragen meekrijgt:
 - ontwikkel een procedure voor import en up-to-date houden van gebouwen en
 adressen uit BAG rekening houdend met edits van mappers
 - ga na welke mogelijkheden de BAG-licentie biedt, hoe we praktisch bij de
 data komen

 En dit dan weer hier terugkoppelt alvorens het ook daadwerkelijk te
 bouwen.

 Ik wil deel van de werkgroep zijn. Wie meer?

Wil ik ook wel. Ik kan nog wel ergens een uurtje per week afsnoepen
(of een paar meer).

Christ van Willegen

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Martijn van Exel]

Dirk,

Goede nieuwe argumenten in de discussie.

Je eerste argument is bedacht vanuit een gebruikersstandpunt. Ik vind
dat we uit moeten gaan van de eigen kracht; wat definieert ons als
OpenStreetMap ten opzichte van andere databoeren. Als we ons gaan
laten leiden door een specifieke groep 'afnemers' dan gaat onze
uniciteit verloren. Bovendien klopt het niet -- er is geen sprake van
enige regionale consistentie van dekking van adressen of zelfs maar
adresranges in OSM. Een potentiële gebruiker zal dus hoe dan ook de
data-situatie per regio moeten bekijken en hun software en
dataverwerking daarop aan moeten passen.

Je tweede argument vóór de import is sterk. Wat motiveert mappers om
dat soort informatie in te brengen als het gewoon op straat ligt? Niet
veel mensen zullen nog huisnummers gaan invoeren.. Daar is geen eer
meer aan te behalen. Er komt dan een soort kunstmatige scheiding
tussen wat nog interessant is om te mappen en wat niet meer, omdat die
data er al is èn er geen toegevoegde waarde is in het 'warm' mappen.
Als de ontwikkelingen zo doorgaan ligt straks alle overheidsdata op
straat en heeft OSM zichzelf helemaal overbodig gemaakt voor wat
betreft de topografie. Dus dan maar opslokken en verbeteren of
gebruiken als inspiratie?

Ik zie het als een groot dilemma! En daarom goed dat we erover discussiëren.

Martijn

2011/8/30  dbuss...@goudappel.nl:
 - ontwikkel een procedure voor import en up-to-date houden van gebouwen en
 adressen uit BAG rekening houdend met edits van mappers

Je hebt mijn reserveringen gelezen over de (on)mogelijkheden omtrent
dit vraagstuk. Ik wil mijn ideeen graag inbrengen als die werkgroep er
komt.

Let op voor eindeloos polderen: een werkgroep moet een leider, een
trekker hebben. Niet alleen maar deelnemers. Ik ben niet meer in de
positie om zo'n rol te vervullen, maar misschien kun jij dat dan doen.
Veel succces hoe dan ook.

-- 
martijn van exel
schaaltreinen.nl

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Oliver Heesakkers]

Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
 2011/8/28 Nico Witteman n...@wittyman.nl:
 (...)
 
  2.   Zijn er plannen om de huisnummers van BAG-viewer
  http://bagviewer.geodan.nl/index.html te gaan importeren?
 
 Zie het mailinglijst-archief, er zijn volgens mij geen concrete
 plannen om de BAG-huisnummers te importeren.
 Ik ben er geen voorstander van. Bij een import moet je ook nadenken
 over hoe die geimporteerde data bij wordt gehouden; van de BAG komt
 maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol
 als je ook die mutaties opneemt. Maar hoe moet dat dan met
 adresobjecten die ondertussen door een echt persoon zijn bijgewerkt?
 Dat zijn moeilijke vragen.
 

Is er sinds die discussie / call to arms eind mei uberhaupt nog iets 
ondernomen op dit gebied?

Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De 
nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien zijn 
het juist de regelmatige updates die deze informatie waardevoller maken dan 
3dShapes.
Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu 
al gruwelijk achterhaald.

Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar 
juist BAG-data voldoet aan een basis wens voor de moderne navigatie-gebruiker, 
namelijk plaatsbepaling op huisnummerniveau.

Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates 
aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door 
de community aangebrachte wijzigingen zo respectvol mogelijk behandelen.
Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een 
soort werkgroep opgezet moeten worden om deze uit te werken en een import zo 
soepel mogelijk te laten verlopen.
Ook bestaan er wellicht nog enkele vraagtekens omtrent het licentie-vraagstuk, 
maar dat zou het ministerie / de gemeentes definitief moeten kunnen 
beantwoorden.

Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven, 
want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron 
doen.

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Floris Looijesteijn]

Er zijn voor en tegenstanders :)

Ik ben zelf voorstander van zoveel mogelijk data in OpenStreetMap, als
het tenminste nuttig is
voor navigeren. En daar lijkt me in dit geval geen twijfel over mogelijk.

Ik voer trouwens ook vrijwel geen huisnummers meer in tegenwoordig...

Groet,
Floris

2011/8/29 Oliver Heesakkers o...@heesakkers.info:
 Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
 2011/8/28 Nico Witteman n...@wittyman.nl:
 (...)

  2.       Zijn er plannen om de huisnummers van BAG-viewer
  http://bagviewer.geodan.nl/index.html te gaan importeren?

 Zie het mailinglijst-archief, er zijn volgens mij geen concrete
 plannen om de BAG-huisnummers te importeren.
 Ik ben er geen voorstander van. Bij een import moet je ook nadenken
 over hoe die geimporteerde data bij wordt gehouden; van de BAG komt
 maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol
 als je ook die mutaties opneemt. Maar hoe moet dat dan met
 adresobjecten die ondertussen door een echt persoon zijn bijgewerkt?
 Dat zijn moeilijke vragen.


 Is er sinds die discussie / call to arms eind mei uberhaupt nog iets
 ondernomen op dit gebied?

 Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De
 nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien zijn
 het juist de regelmatige updates die deze informatie waardevoller maken dan
 3dShapes.
 Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu
 al gruwelijk achterhaald.

 Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar
 juist BAG-data voldoet aan een basis wens voor de moderne navigatie-gebruiker,
 namelijk plaatsbepaling op huisnummerniveau.

 Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates
 aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door
 de community aangebrachte wijzigingen zo respectvol mogelijk behandelen.
 Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een
 soort werkgroep opgezet moeten worden om deze uit te werken en een import zo
 soepel mogelijk te laten verlopen.
 Ook bestaan er wellicht nog enkele vraagtekens omtrent het licentie-vraagstuk,
 maar dat zou het ministerie / de gemeentes definitief moeten kunnen
 beantwoorden.

 Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven,
 want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron
 doen.

 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://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] BAG (Was: Diverse vragen)

[Floris Looijesteijn]

ik zie wel mogelijkheden voor een update script.
ik zeg niet dat ik het ga maken :) maar het is wel mogelijk.

groet,
floris

2011/8/29 Martijn van Exel m...@rtijn.org:
 I2011/8/29 Oliver Heesakkers o...@heesakkers.info:
 Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
 2011/8/28 Nico Witteman n...@wittyman.nl:
 (...)

  2.       Zijn er plannen om de huisnummers van BAG-viewer
  http://bagviewer.geodan.nl/index.html te gaan importeren?

 Zie het mailinglijst-archief, er zijn volgens mij geen concrete
 plannen om de BAG-huisnummers te importeren.
 Ik ben er geen voorstander van. Bij een import moet je ook nadenken
 over hoe die geimporteerde data bij wordt gehouden; van de BAG komt
 maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol
 als je ook die mutaties opneemt. Maar hoe moet dat dan met
 adresobjecten die ondertussen door een echt persoon zijn bijgewerkt?
 Dat zijn moeilijke vragen.


 Is er sinds die discussie / call to arms eind mei uberhaupt nog iets
 ondernomen op dit gebied?

 Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De
 nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien 
 zijn
 het juist de regelmatige updates die deze informatie waardevoller maken dan
 3dShapes.
 Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu
 al gruwelijk achterhaald.
 Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar
 juist BAG-data voldoet aan een basis wens voor de moderne 
 navigatie-gebruiker,
 namelijk plaatsbepaling op huisnummerniveau.

 Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates
 aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door
 de community aangebrachte wijzigingen zo respectvol mogelijk behandelen.
 Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een
 soort werkgroep opgezet moeten worden om deze uit te werken en een import zo
 soepel mogelijk te laten verlopen.
 Ook bestaan er wellicht nog enkele vraagtekens omtrent het 
 licentie-vraagstuk,
 maar dat zou het ministerie / de gemeentes definitief moeten kunnen
 beantwoorden.

 Het is niet alleen een kwestie van nut voor de eindgebruiker. Als
 iemand een navigatie-app wil maken of een website met een
 routeplanner, kan hij prima 'best of breed' datasets combineren. Dat
 betekent nog niet dat al die data in OSM hoeft te zitten. Bij een
 import moet je volgens mij op de eerste plaats uitgaan van het nut
 voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker.
 Die ken je immers niet - wat voor de ene groep gebruikers een heel
 nuttig thema is, is voor een andere categorie volstrekt irrelevant.

 Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten 
 aflezen:
 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld
 bijdragen aan een beter publiek gezicht van het project. De
 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid
 daarvan kunt zetten (zie hieronder), heeft een mooiere kaart
 opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart,
 aantrekkelijker door geworden.
 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een
 impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een
 eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit
 aangetoond, dat de AND-import en ook de TIGER-import hier in de VS
 daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers
 liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit
 misschien ook -- dan vanuit een blanco vel. Weet iemand van een
 onderzoek dat dit argument ondersteunt of ontkracht?

 Naast deze criteria is volgens mij het 'data bij de bron'-argument
 heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij
 de organisatie die verantwoordelijk is voor de productie.

 Wat mij betreft is voor wat betreft de BAG-gegevens het laatste
 argument doorslaggevend: het betreft hier een landsdekkende, complexe
 databron met maandelijkse mutaties. Wat haal je je op de hals als je
 deze data in OSM importeert? Je kunt dat bijna alleen maar éénmalig
 doen, wat betekent dat het merendeel van de BAG-data in OSM langzamaan
 zal verouderen, terwijl bij de bron (het Kadaster) elke maand frisse
 data te halen is. Bedenk je eens wat dat betekent voor de kwaliteit
 van OpenStreetMap over een jaar of drie. Op de korte termijn is het
 een leuke winstpakker, maar op de lange termijn brengt het schade aan
 het project toe.


 Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven,
 want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron
 doen.

 We kunnen natuurlijk wel allerlei andere dingen met de BAG-gegevens
 doen. We kunnen tools maken die kijken waar we straten missen. We
 kunnen tools maken die ons erop attenderen dat er in een bepaald
 gebied veel nieuwe adressen zijn bijgekomen: tijd om er eens langs te
 gaan met een mapping party.
 --
 

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Lennard]

On 29-8-2011 23:44, Floris Looijesteijn wrote:

ik zie wel mogelijkheden voor een update script.
ik zeg niet dat ik het ga maken :) maar het is wel mogelijk.


Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand 
liggende, maar ook een vergelijking op geometrie kan. Je krijgt te maken 
met onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt 
het dan weer af van wat er aangepast is: tags of vorm.


--
Lennard

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Floris Looijesteijn]

ik zat er zelfs aan te denken om de bag-id - osm-id koppeling buiten
de osm database te houden om vervuiling
tegen te gaan. maar mogelijkheden genoeg...

gr,
floris

2011/8/29 Lennard l...@xs4all.nl:
 On 29-8-2011 23:44, Floris Looijesteijn wrote:

 ik zie wel mogelijkheden voor een update script.
 ik zeg niet dat ik het ga maken :) maar het is wel mogelijk.

 Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende,
 maar ook een vergelijking op geometrie kan. Je krijgt te maken met
 onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan
 weer af van wat er aangepast is: tags of vorm.

 --
 Lennard

 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://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] BAG (Was: Diverse vragen)

[drek]

Op 29-08-11 22:42, Martijn van Exel schreef:
Naast deze criteria is volgens mij het 'data bij de bron'-argument 
heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij 
de organisatie die verantwoordelijk is voor de productie. Wat mij 
betreft is voor wat betreft de BAG-gegevens het laatste argument 
doorslaggevend: het betreft hier een landsdekkende, complexe databron 
met maandelijkse mutaties. Wat haal je je op de hals als je deze data 
in OSM importeert? Je kunt dat bijna alleen maar éénmalig doen, wat 
betekent dat het merendeel van de BAG-data in OSM langzamaan zal 
verouderen, terwijl bij de bron (het Kadaster) elke maand frisse data 
te halen is. Bedenk je eens wat dat betekent voor de kwaliteit van 
OpenStreetMap over een jaar of drie. Op de korte termijn is het een 
leuke winstpakker, maar op de lange termijn brengt het schade aan het 
project toe.

Dit snap ik niet... BAG-data verouderen, maar dat doet 3dShapes toch ook?
Mijn vraag is dan ook: zijn BAG-data beter (nauwkeuriger, 
gedetailleerder) dan 3dShapes? Hoe veel moeite is het om de data in te 
passen?


Groeten, André

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Oliver Heesakkers]

Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel:
 I2011/8/29 Oliver Heesakkers o...@heesakkers.info:
  Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
  2011/8/28 Nico Witteman n...@wittyman.nl:
  (...)
  
   2.   Zijn er plannen om de huisnummers van BAG-viewer
   http://bagviewer.geodan.nl/index.html te gaan importeren?
  
  Zie het mailinglijst-archief, er zijn volgens mij geen concrete
  plannen om de BAG-huisnummers te importeren.
  Ik ben er geen voorstander van. Bij een import moet je ook nadenken
  over hoe die geimporteerde data bij wordt gehouden; van de BAG komt
  maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol
  als je ook die mutaties opneemt. Maar hoe moet dat dan met
  adresobjecten die ondertussen door een echt persoon zijn bijgewerkt?
  Dat zijn moeilijke vragen.
  
  Is er sinds die discussie / call to arms eind mei uberhaupt nog iets
  ondernomen op dit gebied?
  
  Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De
  nauwkeurigheid is veel groter en de informatie is uitgebreider.
  Bovendien zijn het juist de regelmatige updates die deze informatie
  waardevoller maken dan 3dShapes.
  Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die
  informatie nu al gruwelijk achterhaald.
  Sommige imports zijn zinvoller dan anderen (powerlines, datakabels),
  maar
  juist BAG-data voldoet aan een basis wens voor de moderne
  navigatie-gebruiker, namelijk plaatsbepaling op huisnummerniveau.
  
  Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende
  updates aangepakt moeten worden, zodat we dubbel getekende gebouwen
  voorkomen en door de community aangebrachte wijzigingen zo respectvol
  mogelijk behandelen. Daarvoor zijn al enkele oplossingen aangedragen,
  maar er zal toch echt een soort werkgroep opgezet moeten worden om deze
  uit te werken en een import zo soepel mogelijk te laten verlopen.
  Ook bestaan er wellicht nog enkele vraagtekens omtrent het
  licentie-vraagstuk, maar dat zou het ministerie / de gemeentes
  definitief moeten kunnen beantwoorden.
 
 Het is niet alleen een kwestie van nut voor de eindgebruiker. Als
 iemand een navigatie-app wil maken of een website met een
 routeplanner, kan hij prima 'best of breed' datasets combineren. Dat
 betekent nog niet dat al die data in OSM hoeft te zitten. Bij een
 import moet je volgens mij op de eerste plaats uitgaan van het nut
 voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker.
 Die ken je immers niet - wat voor de ene groep gebruikers een heel
 nuttig thema is, is voor een andere categorie volstrekt irrelevant.

Key:addr is al een geaccepteerd onderdeel van de OSM-database en wordt in 
meerdere landen toegepast. Het is niet logisch om de Nederlandse huisnummers 
in een aparte database te gaan verstoppen terwijl de rest van de wereld zijn 
huisnummers wel gewoon in de OSM-database heeft zitten. Zelfs seamarks, 
stroomkabels en GSM-masten worden opgenomen in de database. Dat had van mij 
best in een aparte database gemogen omdat het geen recht doet aan de core 
functie van een streetmap, de BAG gegevens doen dat echter wel.

 
 Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten
 aflezen: 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld
 bijdragen aan een beter publiek gezicht van het project. De
 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid
 daarvan kunt zetten (zie hieronder), heeft een mooiere kaart
 opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart,
 aantrekkelijker door geworden.
 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een
 impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een
 eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit
 aangetoond, dat de AND-import en ook de TIGER-import hier in de VS
 daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers
 liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit
 misschien ook -- dan vanuit een blanco vel. Weet iemand van een
 onderzoek dat dit argument ondersteunt of ontkracht?

Ik denk juist dat een potentiele mapper bij een eerste blik op de website zal 
zien dat zijn gebied prima in elkaar zit en geen reden ziet een account te 
maken om aanpassingen te doen, maar zoals je zelf ook al zegt is dat nooit 
hard te maken.

Tegelijkertijd is de mate waarin het product af is van belang voor het nut 
van OSM voor de eindgebruiker. Deur tot deur navigatie is tegenwoordig de 
standaard in navigatie. 

Er bestaat dus een spanningsveld tussen mensen het product OSM slijten en 
mensen actief aan het mappen krijgen. Na de AND en 3dShapes imports denk ik 
dat je je toch vooral op het eerste moet richten en daarbij kan een BAG-import 
een belangrijke rol spelen.

 
 Naast deze criteria is volgens mij het 'data bij de bron'-argument
 heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij
 de organisatie die verantwoordelijk is 

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Martijn van Exel]

2011/8/29 Lennard l...@xs4all.nl:
 On 29-8-2011 23:44, Floris Looijesteijn wrote:

 ik zie wel mogelijkheden voor een update script.
 ik zeg niet dat ik het ga maken :) maar het is wel mogelijk.

 Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende,
 maar ook een vergelijking op geometrie kan. Je krijgt te maken met
 onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan
 weer af van wat er aangepast is: tags of vorm.

Yep, een update-script kan, maar de crux is hoe je beslist welke
updates voorrang genieten en welke criteria je daarvoor aanhoudt. Dat
is heel lastig omdat de meetbare grootte van de aanpassing tussen twee
BAG-versies niet evenredig hoeft te zijn met de 'waarde' ervan. Hoe
wil je dat oplossen?

-- 
martijn van exel
schaaltreinen.nl

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Martijn van Exel]

2011/8/29 drek d...@drek.nl:
 Op 29-08-11 22:42, Martijn van Exel schreef:

 Naast deze criteria is volgens mij het 'data bij de bron'-argument heel
 belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij de
 organisatie die verantwoordelijk is voor de productie. Wat mij betreft is
 voor wat betreft de BAG-gegevens het laatste argument doorslaggevend: het
 betreft hier een landsdekkende, complexe databron met maandelijkse mutaties.
 Wat haal je je op de hals als je deze data in OSM importeert? Je kunt dat
 bijna alleen maar éénmalig doen, wat betekent dat het merendeel van de
 BAG-data in OSM langzamaan zal verouderen, terwijl bij de bron (het
 Kadaster) elke maand frisse data te halen is. Bedenk je eens wat dat
 betekent voor de kwaliteit van OpenStreetMap over een jaar of drie. Op de
 korte termijn is het een leuke winstpakker, maar op de lange termijn brengt
 het schade aan het project toe.

 Dit snap ik niet... BAG-data verouderen, maar dat doet 3dShapes toch ook?
 Mijn vraag is dan ook: zijn BAG-data beter (nauwkeuriger, gedetailleerder)
 dan 3dShapes? Hoe veel moeite is het om de data in te passen?

Ja, BAG-data is beter (recenter, betere geometrie, veel meer atribuut-data).

En inderdaad, het probleem met verouderende data treft 3DShapes eveneens.
Kijk maar eens welk percentage van de 3DShapes-data nog nooit is
aangeraakt sinds de import. Datzelfde geldt trouwens in mindere mate
voor de AND-gegevens. De vraag is: beter (steeds) oude data dan géén
data? Dat moet je je per dataset afvragen.

-- 
martijn van exel
schaaltreinen.nl

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

Re: [OSM-talk-nl] BAG (Was: Diverse vragen)

[Martijn van Exel]

2011/8/29 Oliver Heesakkers o...@heesakkers.info:
 Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel:
 I2011/8/29 Oliver Heesakkers o...@heesakkers.info:
  Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
  2011/8/28 Nico Witteman n...@wittyman.nl:
  (...)
  
   2.       Zijn er plannen om de huisnummers van BAG-viewer
   http://bagviewer.geodan.nl/index.html te gaan importeren?
 
  Zie het mailinglijst-archief, er zijn volgens mij geen concrete
  plannen om de BAG-huisnummers te importeren.
  Ik ben er geen voorstander van. Bij een import moet je ook nadenken
  over hoe die geimporteerde data bij wordt gehouden; van de BAG komt
  maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol
  als je ook die mutaties opneemt. Maar hoe moet dat dan met
  adresobjecten die ondertussen door een echt persoon zijn bijgewerkt?
  Dat zijn moeilijke vragen.
 
  Is er sinds die discussie / call to arms eind mei uberhaupt nog iets
  ondernomen op dit gebied?
 
  Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De
  nauwkeurigheid is veel groter en de informatie is uitgebreider.
  Bovendien zijn het juist de regelmatige updates die deze informatie
  waardevoller maken dan 3dShapes.
  Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die
  informatie nu al gruwelijk achterhaald.
  Sommige imports zijn zinvoller dan anderen (powerlines, datakabels),
  maar
  juist BAG-data voldoet aan een basis wens voor de moderne
  navigatie-gebruiker, namelijk plaatsbepaling op huisnummerniveau.
 
  Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende
  updates aangepakt moeten worden, zodat we dubbel getekende gebouwen
  voorkomen en door de community aangebrachte wijzigingen zo respectvol
  mogelijk behandelen. Daarvoor zijn al enkele oplossingen aangedragen,
  maar er zal toch echt een soort werkgroep opgezet moeten worden om deze
  uit te werken en een import zo soepel mogelijk te laten verlopen.
  Ook bestaan er wellicht nog enkele vraagtekens omtrent het
  licentie-vraagstuk, maar dat zou het ministerie / de gemeentes
  definitief moeten kunnen beantwoorden.

 Het is niet alleen een kwestie van nut voor de eindgebruiker. Als
 iemand een navigatie-app wil maken of een website met een
 routeplanner, kan hij prima 'best of breed' datasets combineren. Dat
 betekent nog niet dat al die data in OSM hoeft te zitten. Bij een
 import moet je volgens mij op de eerste plaats uitgaan van het nut
 voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker.
 Die ken je immers niet - wat voor de ene groep gebruikers een heel
 nuttig thema is, is voor een andere categorie volstrekt irrelevant.

 Key:addr is al een geaccepteerd onderdeel van de OSM-database en wordt in
 meerdere landen toegepast. Het is niet logisch om de Nederlandse huisnummers
 in een aparte database te gaan verstoppen terwijl de rest van de wereld zijn
 huisnummers wel gewoon in de OSM-database heeft zitten. Zelfs seamarks,
 stroomkabels en GSM-masten worden opgenomen in de database. Dat had van mij
 best in een aparte database gemogen omdat het geen recht doet aan de core
 functie van een streetmap, de BAG gegevens doen dat echter wel.

Dat laat onverlet dat er verschillende manieren zijn om die adressen
in de database te krijgen. Ik denk dat het importeren van BAG-gegevens
alleen omdat 'het er is' en omdat er een standaard in OSM is om die
adressen te coderen geen goed idee is. Die zee-elementen en GSM-masten
zijn ook ooit geïmporteerd omdat de data 'er nu eenmaal was' en er een
tag in OSM voor bestond. Iedereen heeft zijn eigen ideeën over wat er
wel en wat er niet in OpenStreetMap thuishoort - de discussies
daarover woeden bij mappen èn bij imports. Die discussie zou wat mij
betreft niet leidend moeten zijn voor de beslissing al dan niet over
te gaan tot een import.


 Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten
 aflezen: 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld
 bijdragen aan een beter publiek gezicht van het project. De
 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid
 daarvan kunt zetten (zie hieronder), heeft een mooiere kaart
 opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart,
 aantrekkelijker door geworden.
 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een
 impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een
 eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit
 aangetoond, dat de AND-import en ook de TIGER-import hier in de VS
 daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers
 liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit
 misschien ook -- dan vanuit een blanco vel. Weet iemand van een
 onderzoek dat dit argument ondersteunt of ontkracht?

 Ik denk juist dat een potentiele mapper bij een eerste blik op de website zal
 zien dat zijn gebied prima in elkaar zit en geen reden ziet een account te
 maken om 

Re: [OSM-talk-nl] BAG

[Floris Looijesteijn]

Aangezien er dus al BAG data in OSM zit neem ik aan dat er toch goed
naar dat hergebruik gekeken is?

Gr,
Floris

PS. is er nog steeds behoefte om bij elkaar te gaan zitten, of is deze
thread net zo handig?

2011/6/1  stegg...@steggink.org:
 Quoting Vincent Zweije vinc...@zweije.nl:

 On Wed, Jun 01, 2011 at 04:22:05PM +0200, Jeroen Muris wrote:

 ||  De BAG wordt door iedere gemeente afzonderlijk bijgehouden (en via
 ||  XML berichten met een 'landelijke voorziening' uitgewisseld). Nu
 ||  kan het voorkomen dat een woonplaats aan, op, of over de grens van
 ||  een gemeente ligt; dan zal elke gemeenten die objecten (panden,
 ||  nummeraanduidingen, ...) in die woonplaats heeft de woonplaats in
 ||  haar administratie opnemen. Afhankelijk van hoe de BAG dan
 ||  bevraagd wordt kan één woonplaats dan meermalen voorkomen.

 Hee!

 Ik lees hieruit dat de gemeenten elkaar, dan wel een centrale BAG,
 up to date houden met (roffel) updates!

 Als we die nou kunnen krijgen? Dat zou wel eens heel nuttig kunnen zijn
 voor het up to date houden van onze BAG informatie, mochten we een BAG
 import of tussenbestand maken.


 We moeten ons dus als de wiedeweerga aansluiten bij de Landelijke
 Voorziening en zorgen dat we voor 1 juli de BAG van heel Nederland gratis
 binnen hebben. ;) Alle gemeenten zijn ondertussen aangesloten, dus de LV is
 gevuld. Zodra er duidelijkheid is over het hergebruik is van de BAG-data,
 kunnen we de nuttige delen hieruit importeren in OSM.

 Meer info:
 http://bag.vrom.nl/de_bag_gebruiken/vraag_en_antwoord#v8b26cdcfe276bdac8813e5709073a6c0
 Martijn, Jeroen: weten jullie of deze FAQ nog actueel is?

 Groeten,

 Frank

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


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