Re: [OSM-talk-be] GRB open data

2016-06-07 Thread Marc Gemis 
FYI, some people will also map amenity=pub, restaurant, etc. as the
area for e.g. the pub + terrace + parking space and put the address on
that area (was also discussed on the GB--mailing list in order to seek
a common way of mapping amenities.)
Others might map this as landuse=retail.

Furthermore there have been discussions in the past to have some kind
of landuse dedicated for schools, again with the purpose to have more
similarity with e.g. building=house,landuse=residential.

So, you can see there are all kinds of ideas and methods to tag.

regards

m

On Tue, Jun 7, 2016 at 8:19 PM, Glenn Plas  wrote:
> On 07-06-16 19:04, Jo wrote:
>> I don't think there is a separate landuse=school. Schools generally fall
>> inside a landuse=residential.
>>
>> It's possible to tag building=school. If there is more than 1 building,
>> add an amenity=school for the school grounds. I'd put the addr
>> information on those, except if all the buildings have different addresses.
>>
>> If there is 1 building with 1 school, I guess it can get amenity=school
>> together with building=school.
>>
>
> Duplicate housenumbers on seperate buildings is -for certain- an error,
> if there are plenty of buildings in a school, then you could create a
> relation and addr:* it once instead of all buildings, or map the school
> grounds as per Jo's suggestion. Also a good idea is to create an amenity
> relation of buildings and address that one.
>
> It's also not uncommon that an amenity=school contains different
> addresses on the same building and even different addresses on different
> buildings all belonging to the same school.  It's not easy to sort this
> out ...   An alternative idea would be to just map the entrances and
> address those instead of the buildings.
>
> It's still 'wrong' if there is a physical tag missing logic dictates
> .e.g building ...  In any case.. it's -sometimes- terrible for routing
> and geocoding purposes due to the possible size of an amenity giving
> distorted results.   So far the theory...
>
> I tested it with geocoding and it seems to be supported though.  I find
> exact matches when looking for onjects that only have address
> information present on amenities, so  I can confirm nominatim looks at them.
>
> That being said, just discovered I actually mapped this myself in the
> past to 'solve' multiple buildings sporting the same address data, but
> also to support some of the buildings having a different address yet
> they still belong to the same school.
>
> The way I formed my opinion is by trying to find anything on addr:*
> combined with an amenity on the wiki and I remarkably didn't find
> anything to confirm nor deny that idea.
>
> I remember mapping this school:
> http://www.openstreetmap.org/way/205862112#map=19/50.96950/4.44678
>
> Sure enough, just an amenity.  In the light of about 111K addressed
> amenities in the UK as Marc mentions I would think this is de facto
> accepted but not well documented.
>
> So, I'm adjusting my opinion on this now and consider it OK instead of
> wrong.
>
> Glenn
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] GRB open data

2016-06-07 Thread Glenn Plas 
On 07-06-16 19:04, Jo wrote:
> I don't think there is a separate landuse=school. Schools generally fall
> inside a landuse=residential.
> 
> It's possible to tag building=school. If there is more than 1 building,
> add an amenity=school for the school grounds. I'd put the addr
> information on those, except if all the buildings have different addresses.
> 
> If there is 1 building with 1 school, I guess it can get amenity=school
> together with building=school.
> 

Duplicate housenumbers on seperate buildings is -for certain- an error,
if there are plenty of buildings in a school, then you could create a
relation and addr:* it once instead of all buildings, or map the school
grounds as per Jo's suggestion. Also a good idea is to create an amenity
relation of buildings and address that one.

It's also not uncommon that an amenity=school contains different
addresses on the same building and even different addresses on different
buildings all belonging to the same school.  It's not easy to sort this
out ...   An alternative idea would be to just map the entrances and
address those instead of the buildings.

It's still 'wrong' if there is a physical tag missing logic dictates
.e.g building ...  In any case.. it's -sometimes- terrible for routing
and geocoding purposes due to the possible size of an amenity giving
distorted results.   So far the theory...

I tested it with geocoding and it seems to be supported though.  I find
exact matches when looking for onjects that only have address
information present on amenities, so  I can confirm nominatim looks at them.

That being said, just discovered I actually mapped this myself in the
past to 'solve' multiple buildings sporting the same address data, but
also to support some of the buildings having a different address yet
they still belong to the same school.

The way I formed my opinion is by trying to find anything on addr:*
combined with an amenity on the wiki and I remarkably didn't find
anything to confirm nor deny that idea.

I remember mapping this school:
http://www.openstreetmap.org/way/205862112#map=19/50.96950/4.44678

Sure enough, just an amenity.  In the light of about 111K addressed
amenities in the UK as Marc mentions I would think this is de facto
accepted but not well documented.

So, I'm adjusting my opinion on this now and consider it OK instead of
wrong.

Glenn



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

Re: [OSM-talk-be] GRB open data

2016-06-07 Thread Jo 
I don't think there is a separate landuse=school. Schools generally fall
inside a landuse=residential.

It's possible to tag building=school. If there is more than 1 building, add
an amenity=school for the school grounds. I'd put the addr information on
those, except if all the buildings have different addresses.

If there is 1 building with 1 school, I guess it can get amenity=school
together with building=school.

Polyglot

Op 7 juni 2016 18:34 schreef Marc Gemis :

> amenity=school + address information is not so unusual  111.000 of
> them are tagged with some address information according to taginfo. I
> think the UK community tagged them like this during their quarterly
> project. (I'm too lazy to look up their discussions to get
> confirmation about this)
> The wiki page of school also mentions the combination with the address tag.
>
> regards
>
>
> m
>
> 2016-06-07 15:36 GMT+02:00 Glenn Plas :
> > On 07-06-16 12:32, Killian De Volder wrote:
> >> On 02-06-16 17:44, Glenn Plas wrote:
> >>
> >>> Ik heb een tool gemaakt die redelijk af is maar er is zit een wat
> >>> diepere problematiek in de data die ik niet in 1 ,2 .. 3 kan uitleggen
> >>> op verstaanbare manier.
> >>>
> >>
> >> Nog een randgeval tegen gekomen:
> >>
> >> http://www.openstreetmap.org/way/246290812
> >>
> >> Als je een landuse (in dit geval school) tagged met een adres heb je
> nog steeds een merge te doen.
> >
> > Dit is geen landuse maar een amenity dat je ws op doelde.   IMHO dit is
> > verkeerd, een addr:* tag hoort op een node, een entrance of een gebouw
> > te staan.  Tenzij een amenity ook een gebouw is kan dit wel.  Maar
> > adressen horen niet toe tot een streek. (die kan heel groot zijn
> > waardoor addressen minder nauwkeurig wordt).
> >
> > src: http://wiki.openstreetmap.org/wiki/Addresses
> >
> >> Nu dit kunnen we in principe wel opvangen met QA check na een
> semiautomatische import.
> >
> > ervoor bedoel je!  de manier dat ik de import visualiseer is dat een
> > levende mens dit soort issues ziet en ze oplost.
> >
> >>
> >> PS, Welke behoud ik ?
> >
> > Wat denk je zelf ?
> >
> >
> >
> > Glenn
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] GRB open data

2016-06-07 Thread Marc Gemis 
amenity=school + address information is not so unusual  111.000 of
them are tagged with some address information according to taginfo. I
think the UK community tagged them like this during their quarterly
project. (I'm too lazy to look up their discussions to get
confirmation about this)
The wiki page of school also mentions the combination with the address tag.

regards


m

2016-06-07 15:36 GMT+02:00 Glenn Plas :
> On 07-06-16 12:32, Killian De Volder wrote:
>> On 02-06-16 17:44, Glenn Plas wrote:
>>
>>> Ik heb een tool gemaakt die redelijk af is maar er is zit een wat
>>> diepere problematiek in de data die ik niet in 1 ,2 .. 3 kan uitleggen
>>> op verstaanbare manier.
>>>
>>
>> Nog een randgeval tegen gekomen:
>>
>> http://www.openstreetmap.org/way/246290812
>>
>> Als je een landuse (in dit geval school) tagged met een adres heb je nog 
>> steeds een merge te doen.
>
> Dit is geen landuse maar een amenity dat je ws op doelde.   IMHO dit is
> verkeerd, een addr:* tag hoort op een node, een entrance of een gebouw
> te staan.  Tenzij een amenity ook een gebouw is kan dit wel.  Maar
> adressen horen niet toe tot een streek. (die kan heel groot zijn
> waardoor addressen minder nauwkeurig wordt).
>
> src: http://wiki.openstreetmap.org/wiki/Addresses
>
>> Nu dit kunnen we in principe wel opvangen met QA check na een 
>> semiautomatische import.
>
> ervoor bedoel je!  de manier dat ik de import visualiseer is dat een
> levende mens dit soort issues ziet en ze oplost.
>
>>
>> PS, Welke behoud ik ?
>
> Wat denk je zelf ?
>
>
>
> Glenn
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] GRB open data

2016-06-07 Thread Glenn Plas 
On 07-06-16 12:32, Killian De Volder wrote:
> On 02-06-16 17:44, Glenn Plas wrote:
> 
>> Ik heb een tool gemaakt die redelijk af is maar er is zit een wat
>> diepere problematiek in de data die ik niet in 1 ,2 .. 3 kan uitleggen
>> op verstaanbare manier.
>>
> 
> Nog een randgeval tegen gekomen:
> 
> http://www.openstreetmap.org/way/246290812
> 
> Als je een landuse (in dit geval school) tagged met een adres heb je nog 
> steeds een merge te doen.

Dit is geen landuse maar een amenity dat je ws op doelde.   IMHO dit is
verkeerd, een addr:* tag hoort op een node, een entrance of een gebouw
te staan.  Tenzij een amenity ook een gebouw is kan dit wel.  Maar
adressen horen niet toe tot een streek. (die kan heel groot zijn
waardoor addressen minder nauwkeurig wordt).

src: http://wiki.openstreetmap.org/wiki/Addresses

> Nu dit kunnen we in principe wel opvangen met QA check na een 
> semiautomatische import.

ervoor bedoel je!  de manier dat ik de import visualiseer is dat een
levende mens dit soort issues ziet en ze oplost.

> 
> PS, Welke behoud ik ?

Wat denk je zelf ?



Glenn


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

Re: [OSM-talk-be] GRB open data

2016-06-07 Thread Killian De Volder 
On 02-06-16 17:44, Glenn Plas wrote:

> Ik heb een tool gemaakt die redelijk af is maar er is zit een wat
> diepere problematiek in de data die ik niet in 1 ,2 .. 3 kan uitleggen
> op verstaanbare manier.
> 

Nog een randgeval tegen gekomen:

http://www.openstreetmap.org/way/246290812

Als je een landuse (in dit geval school) tagged met een adres heb je nog steeds 
een merge te doen.
Nu dit kunnen we in principe wel opvangen met QA check na een semiautomatische 
import.

PS, Welke behoud ik ?

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

Re: [OSM-talk-be] GRB open data

2016-06-03 Thread Glenn Plas 
Hey Killian,

On 02-06-16 22:23, Killian De Volder wrote:
> Glenn,
> 
> Geen nood de enige import die ik gedaan heb is diegene die die jij nadien aan 
> het importeren was.
> (Indien zich U het herinnerd, verder heb ik ook de boot afgehouden.)

Oef de pijn is nu over :)  Ik herinner het me idd, je bent vooral actief
in Stekene/Kemzeke hee.   Dat was de test case waarmee ik de tool heb
ontwikkeld omdat daar bijna geen enkel gebouw stond, ik had een streek
nodig om het te testen/ontwikkelen.

> 
> Verder ik ga er vanuit dat er mensen zijn die manueel/semiautomatisch aan het 
> importen zijn.
> Bewijs:
> Ik + Jij (Glenn): http://www.openstreetmap.org/#map=14/51.2189/4.0546
> http://www.openstreetmap.org/way/107808094#map=19/51.07133/4.72699

Yup, Ik kon ook moeilijk anders om te ontwikkelen, waaruit dus bleek dat
er te weinig source data insteekt.   source:entity=* ontbreekt.  Deze is
nodig omdat UUID's niet uniek zijn (Gba, Gbg, Knw... ze kunnen dezelfde
uuid's bevatten).   Tijdens mijn werken op Stekene ben ik erachter
gekomen dat er plots addressen stonden bij import met men tools op
roof's en garage's.  Dus alle gebouwen daar in Stekene moeten nog een
tag bijkrijgen om aan te duiden vanuit welke bron ze komen.

> 
> Verder had bestaande gebouwen heb ik gewoon aangepast.
> "Megablocks" (10 huizen aan elkaar in een slordige import door 3Dshapes) 
> dacht ik wel verwijderd te hebben, of had ik hiervan zoveel mogelijk nodes 
> moeten hergebruiken ?

3Dshapes is meestal rommel , 't was perfect in het prille begin, maar
die dingen zijn achterhaald, van tijd zien ze een vierkant bos als een
building.  Maar dan nog zou je best de plugin gebruiken om geometries te
mergen.

> 
> Maar als jij er mee bezig bent (ook als is het niet op dit moment) is het 
> goed,
> het is niet dat ik (en hopelijk de rest ook) geen geduld heb. Noch zit er 
> druk achter.

Ik ga proberen deze zomervakantie (binnen kleine maand dus) de draad
terug op te pikken en het grootste probleem op te lossen, nml.  Nodes
mergen tussen de entities in de database.  Nu is een roof niet gekoppeld
aan de building omdat ze de nodes niet delen, maar die nodes staan wel
over elkaar, de reden is omdat het gescheiden bronnen zijn, als je dit
importeert krijgen al die nodes aparte id's waardoor ze over elkaar
liggen.  In JOSM kan je dit wel deels fixen,maar dit is echt niet
handig/gemakkelijk.  Vraag maar aan Marc Gemis:  als je met 750
validation warnings op duplicate nodes zit op klein gebied.

> 
> Maar om eerlijke te zijn zou het wel handig zijn als de huisnummers er eens 
> in geraken ;)
> Maar huisnummers vereisen een gebouw tekenen ... welke met de mogelijkheid 
> tot GRB een beetje extra werk lijkt.

De huisnummers komen automatisch mee met de tool ondertussen, ze worden
gematch aan buildings, achteraf moet je wel echt aan de slag met Sanders
zijn tool omdat wat GRB betreft maar 1 adres per building kan bestaan,
de crab toolset heeft hier een grote meerwaarde bij buildings die bv
addressen bevatten van 2 straten (hoekhuizen etc.)

> Is het plan de nummers mee te nemen in deze procedure ?

Dat is al het geval, je kan de popups enablen en dan zie je de
huisnummers.  http://grbtiles.byteless.net/
Die popup kan annoying zijn, maar dit is work in progress, en vooral
handig voor mezelf gemaakt, het uiteindelijk product gaat beter werken.
Beloofd.

Visueel zie je trouwens ook hoe compleet een adres is, de zwarte
contouren op een gebouw worden dikker naarmate je meer addr:* keys hebt
in de data.  Gebouwen zonder zwarte rand hebben geen adres informatie.

> Indien niet het geval, is er een tussen voorlopige manier dat men dit dan 
> best (of gewoon niet) doet ?
> Vierkante huizen die goed aansluiten bij GRB vorm, of gewoon wachten op de 
> huizen ?

Het is in ieder geval gemakkelijker om geen bestaande buildings te
hebben met de semi-automatische import (vermijd je die problemen).  Maar
ik begrijp je drive om die erin te krijgen.

> Ps.: Thanks for osmose !

Np, heel verslavend hee ?  Ik fix ook graag.  Check mss ook deze eens:

http://osmhv.openstreetmap.de/index.jsp

Mvg,

Glenn



> 
> Mvg,
> Killian De Volder
> 
> 
> On 02-06-16 17:44, Glenn Plas wrote:
>> Hallo,
>>
>> Met enige pijn in het hart lees ik dit.
>>
>> Je kan echt nog niet onbezonnen gaan importeren op deze manier.   Voor
>> de volgende redenen alvast:
>>
>>  - Deze semi-automatische import moet goedgekeurd worden en er moet een
>> case voor worden gemaakt.
>>  - gebouwen zijn maar 1 deeltje van de data, er zit veel meer in
>>  - Als je zomaar importeert zonder er over na te denken voor de
>> opvolging, als je buildings in OSM ramt zonder referenties naar GRB op
>> een gestructureerde manier.
>>
>>
>> Als we echt automatische imports hadden gekozen was het nu reeds over,
>> dus er zijn wel degelijk goede redenen om dit niet zo aan te pakken.
>>
>> Je mag bestaande gebouwen niet zomaar wissen.  je moet een josm plugin
>> tool gebruiken om die te mergen zodat historiek niet verloren gaat.
>>
>>

Re: [OSM-talk-be] GRB open data

2016-06-02 Thread Killian De Volder 
Glenn,

Geen nood de enige import die ik gedaan heb is diegene die die jij nadien aan 
het importeren was.
(Indien zich U het herinnerd, verder heb ik ook de boot afgehouden.)

Verder ik ga er vanuit dat er mensen zijn die manueel/semiautomatisch aan het 
importen zijn.
Bewijs:
Ik + Jij (Glenn): http://www.openstreetmap.org/#map=14/51.2189/4.0546
http://www.openstreetmap.org/way/107808094#map=19/51.07133/4.72699

Verder had bestaande gebouwen heb ik gewoon aangepast.
"Megablocks" (10 huizen aan elkaar in een slordige import door 3Dshapes) dacht 
ik wel verwijderd te hebben, of had ik hiervan zoveel mogelijk nodes moeten 
hergebruiken ?

Maar als jij er mee bezig bent (ook als is het niet op dit moment) is het goed,
het is niet dat ik (en hopelijk de rest ook) geen geduld heb. Noch zit er druk 
achter.

Maar om eerlijke te zijn zou het wel handig zijn als de huisnummers er eens in 
geraken ;)
Maar huisnummers vereisen een gebouw tekenen ... welke met de mogelijkheid tot 
GRB een beetje extra werk lijkt.
Is het plan de nummers mee te nemen in deze procedure ?
Indien niet het geval, is er een tussen voorlopige manier dat men dit dan best 
(of gewoon niet) doet ?
Vierkante huizen die goed aansluiten bij GRB vorm, of gewoon wachten op de 
huizen ?

Ps.: Thanks for osmose !

Mvg,
Killian De Volder


On 02-06-16 17:44, Glenn Plas wrote:
> Hallo,
> 
> Met enige pijn in het hart lees ik dit.
> 
> Je kan echt nog niet onbezonnen gaan importeren op deze manier.   Voor
> de volgende redenen alvast:
> 
>  - Deze semi-automatische import moet goedgekeurd worden en er moet een
> case voor worden gemaakt.
>  - gebouwen zijn maar 1 deeltje van de data, er zit veel meer in
>  - Als je zomaar importeert zonder er over na te denken voor de
> opvolging, als je buildings in OSM ramt zonder referenties naar GRB op
> een gestructureerde manier.
> 
> 
> Als we echt automatische imports hadden gekozen was het nu reeds over,
> dus er zijn wel degelijk goede redenen om dit niet zo aan te pakken.
> 
> Je mag bestaande gebouwen niet zomaar wissen.  je moet een josm plugin
> tool gebruiken om die te mergen zodat historiek niet verloren gaat.
> 
> Als ik het nu zo lees kan je echt beter stoppen met importeren want die
> changesets gaan wss allen moeten weggehaald worden. *zucht*
> 
> Ik heb een tool gemaakt die redelijk af is maar er is zit een wat
> diepere problematiek in de data die ik niet in 1 ,2 .. 3 kan uitleggen
> op verstaanbare manier.
> 
> http://grbtiles.byteless.net/
> 
> Als je bezigheidstherapie wil, probeer dan eens Osmose om de bestaande
> data te verbeteren.
> 
> http://osmose.openstreetmap.fr/en/map/
> 
> Maak een RSS feed aan van je eigen username en sta versteld over welke
> fouten je tegenkomt (ook voor mezelf btw, mistakes happen, skills
> evolueren).
> 
> Nogmaals: importeer aub niets tot we het hebben uitgewerkt.   Ik zit in
> tijdsgebrek de laatste maanden, vandaar dat ik het wat geparkeerd had.
> 
> Al je werk gaat echt voor niets zijn.
> 
> Glenn
> 
> 
> 
> On 02-06-16 16:08, Killian De Volder wrote:
>> Beste allen,
>>
>> "Het zal ni lang duren of iemand is er mee weg... ;-)"
>> Bleek niet te kloppen, (niet dat ik klaag).
>>
>> Bedenkingen:
>> - Bij het invoegen van huizen moet je soms de land-use gebieden mee 
>> verzetten/mergen.
>> - Bestaande gebouwen en lijnen matchen kan lastig te automatiseren zijn.
>>   (Hoewel dicht bijzijnde punten best verplaats kunnen worden bv max 3 
>> meter.)
>> - Hoe later updates van GRB importeren ?
>> - Achterkant huizen zijn "niet te vertrouwen". (De zwarte lijnen/punten, die 
>> door de landmeter, wel)
>>
>> @Glenn Plas: Jij bent ook als eens bezig geweest hiermee.
>> Als jij je ervaringen ook eens kan delen zou dit wenselijk zijn.
>>
>> Dus de vragen die ik mij op dit moment vooral stel:
>>
>> Willen we de data automatisch importeren, of gaan we het manueel doen ?
>>
>> Anders kunnen de manuele mappers dit met gerust hart verder importeren.
>> (En anders zijn ze nu bezig met bezigheids-therapie)
>>
>> En anders moeten we er een rustig werk van maken om al het nodige op te 
>> zetten
>>
>> Als we het automatisch doen zullen we een server/service
>> moeten opzetten zoals de adressen van de CRAB tool maar dan voor GRB.
>>
>> Mvg,
>> Killian De Volder
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-be] GRB open data

2016-06-02 Thread Glenn Plas 
Hallo,

Met enige pijn in het hart lees ik dit.

Je kan echt nog niet onbezonnen gaan importeren op deze manier.   Voor
de volgende redenen alvast:

 - Deze semi-automatische import moet goedgekeurd worden en er moet een
case voor worden gemaakt.
 - gebouwen zijn maar 1 deeltje van de data, er zit veel meer in
 - Als je zomaar importeert zonder er over na te denken voor de
opvolging, als je buildings in OSM ramt zonder referenties naar GRB op
een gestructureerde manier.


Als we echt automatische imports hadden gekozen was het nu reeds over,
dus er zijn wel degelijk goede redenen om dit niet zo aan te pakken.

Je mag bestaande gebouwen niet zomaar wissen.  je moet een josm plugin
tool gebruiken om die te mergen zodat historiek niet verloren gaat.

Als ik het nu zo lees kan je echt beter stoppen met importeren want die
changesets gaan wss allen moeten weggehaald worden. *zucht*

Ik heb een tool gemaakt die redelijk af is maar er is zit een wat
diepere problematiek in de data die ik niet in 1 ,2 .. 3 kan uitleggen
op verstaanbare manier.

http://grbtiles.byteless.net/

Als je bezigheidstherapie wil, probeer dan eens Osmose om de bestaande
data te verbeteren.

http://osmose.openstreetmap.fr/en/map/

Maak een RSS feed aan van je eigen username en sta versteld over welke
fouten je tegenkomt (ook voor mezelf btw, mistakes happen, skills
evolueren).

Nogmaals: importeer aub niets tot we het hebben uitgewerkt.   Ik zit in
tijdsgebrek de laatste maanden, vandaar dat ik het wat geparkeerd had.

Al je werk gaat echt voor niets zijn.

Glenn



On 02-06-16 16:08, Killian De Volder wrote:
> Beste allen,
> 
> "Het zal ni lang duren of iemand is er mee weg... ;-)"
> Bleek niet te kloppen, (niet dat ik klaag).
> 
> Bedenkingen:
> - Bij het invoegen van huizen moet je soms de land-use gebieden mee 
> verzetten/mergen.
> - Bestaande gebouwen en lijnen matchen kan lastig te automatiseren zijn.
>   (Hoewel dicht bijzijnde punten best verplaats kunnen worden bv max 3 meter.)
> - Hoe later updates van GRB importeren ?
> - Achterkant huizen zijn "niet te vertrouwen". (De zwarte lijnen/punten, die 
> door de landmeter, wel)
> 
> @Glenn Plas: Jij bent ook als eens bezig geweest hiermee.
> Als jij je ervaringen ook eens kan delen zou dit wenselijk zijn.
> 
> Dus de vragen die ik mij op dit moment vooral stel:
> 
> Willen we de data automatisch importeren, of gaan we het manueel doen ?
> 
> Anders kunnen de manuele mappers dit met gerust hart verder importeren.
> (En anders zijn ze nu bezig met bezigheids-therapie)
> 
> En anders moeten we er een rustig werk van maken om al het nodige op te zetten
> 
> Als we het automatisch doen zullen we een server/service
> moeten opzetten zoals de adressen van de CRAB tool maar dan voor GRB.
> 
> Mvg,
> Killian De Volder
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-be] GRB open data

2015-12-10 Thread Kurt Roeckx 
On Sun, Dec 06, 2015 at 11:36:01AM +0100, Pieter Colpaert wrote:
> Njah... Het probleem is ook wat dat we iedere dag een nieuwe manuele
> downloadprocedure moeten starten ipv gewoon een URI opnieuw te kunnen
> afhalen.

Ik dacht dat dit allemaal al een tijd beschikbaar was via wms,
inclusief een vector (svg) layer.  Ik heb dat maanden geleden toch al
gebruikt.


Kurt


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

Re: [OSM-talk-be] GRB open data

2015-12-10 Thread Sander Deryckere 
Ik dacht dat ik tamelijk duidelijk was op de wiki. Het GRB was nog niet
open, maar er zit wel data van het CRAB en die kan gebruikt worden.
Gebouwen overtekenen was echter nog niet toegestaan.

http://wiki.openstreetmap.org/wiki/NL:WikiProject_Belgium/Using_AGIV_Crab_data/AGIV_Website_as_Reference

Nu is dat dus wel mogelijk (en moet die pagina geüpdated worden), en heeft
het geen zin om eventuele overgetekende gebouwen te verwijderen. Maar ik
vraag me toch af hoe ik duidelijker kon zijn.

Mvg,
Sander
Op 10-dec.-2015 23:37 schreef "Kurt Roeckx" :

> On Sun, Dec 06, 2015 at 11:36:01AM +0100, Pieter Colpaert wrote:
> > Njah... Het probleem is ook wat dat we iedere dag een nieuwe manuele
> > downloadprocedure moeten starten ipv gewoon een URI opnieuw te kunnen
> > afhalen.
>
> Ik dacht dat dit allemaal al een tijd beschikbaar was via wms,
> inclusief een vector (svg) layer.  Ik heb dat maanden geleden toch al
> gebruikt.
>
>
> Kurt
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] GRB open data

2015-12-06 Thread Pieter Colpaert 
Zouden we geen mirror kunnen opzetten voor deze data (zijn tenslotte 
open data) of deze files torrenten?


Lijkt me beter dan een verschrikkelijk omslachtig downloadformulier 
zonder download resuming. Ook al 2 keer proberen downloaded 
ondertussen... maar sjah.


Pieter

On 06-12-15 10:48, joost schouppe wrote:

Sander,

Je kan ook laag per laag downloaden: minder kans op miserie.

Misschien zijn de "wegverbindingen" van Agiv wel nuttiger als het 
wegenregister: ik denk dat die wegverbindingen volledig zijn voor 
hetgeen ze willen doen, terwijl wegenregister dan wel breder is (ook 
trage wegen etc.), maar minder volledig.


Op 5 december 2015 13:42 schreef Sander Deryckere >:


Hmm, net een poging gedaan om het volledige GRB te downloaden,
maar dat is mislukt.

Het volledige GRB is 15.4GB groot. Maar ergens rond 11GB ging mijn
connectie uit voor even. Normaal is dat geen probleem, en wordt de
download automatisch hervat.

Helaas eist Agiv dat je ingelogd bent om het GRB te downloaden, en
werd mijn request naar een inlogpagina gezonden i.p.v. naar het
echte bestand. Het resultaat is: een nutteloze html pagina in mijn
downloads en die 11GB die al gedownload was is niet meer te vinden.

Dus aan iedereen die de download probeert: doe het met een
stabiele connectie (en zonder pauzes).

Op 4 december 2015 19:23 schreef Marc Gemis >:

cabine : Electrical, gas or other cabine

kan onder man_made=street_cabinet of misschien
pipeline/power=substation afh. van de grootte

in- of uitrit van een parking : highway=service +
service=parking_aisle

dacht ik ook, maar via de discussie op reddit die ik net
gelezen heb
[1] moet de toegangsweg highway=service zijn. Heb dat zelf nog
nooit
zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en ik heb die
wiki pagina al lang niet meer bekeken

[1]

https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
[2]
https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle

2015-12-04 18:55 GMT+01:00 Sander Deryckere
>:
> Ik heb geprobeerd de Agiv en OSM data wat te vergelijken
(onderzoeken welke
> definities gebruikt worden in OSM vs Agiv). Mijn bevindingen
staan hier:
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
>
> In het kort, zeker niet alles is bruikbaar. Deze zijn de
meest bruikbare
> bestanden voor OSM:
>
> * Gbg and delen van Gba: de gebouw contouren, gevels zijn
van goede
> kwaliteit (door landmeters opgemeten), in de achterstukken
kunnen soms wat
> fouten zitten
> * Wvb: middellijnen van straten (met naam, type en andere
data), goede
> kwaliteit, ook niet teveel nodes
> * Wgr en Wlas: middellijnen van grachten, beken en rivieren
(met naam),
> goede kwaliteit, zoals wegen
> * Knw: een hoop verschillende zaken die we mappen mat
man_made=* in OSM
> * Wga: vooral de bushokjes en fietsenstallingen zijn interessant
> * Wgo: vertaling naar de experimentele area:highway tag?
Conversie niet zo
> gemakkelijk
> * Wti : verkeersplateaus
> * Wni: muurtjes en vangrails naast de weg
>
> De rest komt ofwel niet overeen met OSM (hun wegbaan
gebieden nemen ook
> delen van voortuinen in, en de wateroppervlaktes nemen ook
grote delen vaste
> oever in), of heeft geen equivalent in OSM.
>
> Mvg,
> Sander
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
>

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



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




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




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

Re: [OSM-talk-be] GRB open data

2015-12-06 Thread joost schouppe 
Sander,

Je kan ook laag per laag downloaden: minder kans op miserie.

Misschien zijn de "wegverbindingen" van Agiv wel nuttiger als het
wegenregister: ik denk dat die wegverbindingen volledig zijn voor hetgeen
ze willen doen, terwijl wegenregister dan wel breder is (ook trage wegen
etc.), maar minder volledig.

Op 5 december 2015 13:42 schreef Sander Deryckere :

> Hmm, net een poging gedaan om het volledige GRB te downloaden, maar dat is
> mislukt.
>
> Het volledige GRB is 15.4GB groot. Maar ergens rond 11GB ging mijn
> connectie uit voor even. Normaal is dat geen probleem, en wordt de download
> automatisch hervat.
>
> Helaas eist Agiv dat je ingelogd bent om het GRB te downloaden, en werd
> mijn request naar een inlogpagina gezonden i.p.v. naar het echte bestand.
> Het resultaat is: een nutteloze html pagina in mijn downloads en die 11GB
> die al gedownload was is niet meer te vinden.
>
> Dus aan iedereen die de download probeert: doe het met een stabiele
> connectie (en zonder pauzes).
>
> Op 4 december 2015 19:23 schreef Marc Gemis :
>
> cabine : Electrical, gas or other cabine
>>
>> kan onder man_made=street_cabinet of misschien
>> pipeline/power=substation afh. van de grootte
>>
>> in- of uitrit van een parking : highway=service + service=parking_aisle
>>
>> dacht ik ook, maar via de discussie op reddit die ik net gelezen heb
>> [1] moet de toegangsweg highway=service zijn. Heb dat zelf nog nooit
>> zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en ik heb die
>> wiki pagina al lang niet meer bekeken
>>
>> [1]
>> https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
>> [2] https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle
>>
>> 2015-12-04 18:55 GMT+01:00 Sander Deryckere :
>> > Ik heb geprobeerd de Agiv en OSM data wat te vergelijken (onderzoeken
>> welke
>> > definities gebruikt worden in OSM vs Agiv). Mijn bevindingen staan hier:
>> > https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
>> >
>> > In het kort, zeker niet alles is bruikbaar. Deze zijn de meest bruikbare
>> > bestanden voor OSM:
>> >
>> > * Gbg and delen van Gba: de gebouw contouren, gevels zijn van goede
>> > kwaliteit (door landmeters opgemeten), in de achterstukken kunnen soms
>> wat
>> > fouten zitten
>> > * Wvb: middellijnen van straten (met naam, type en andere data), goede
>> > kwaliteit, ook niet teveel nodes
>> > * Wgr en Wlas: middellijnen van grachten, beken en rivieren (met naam),
>> > goede kwaliteit, zoals wegen
>> > * Knw: een hoop verschillende zaken die we mappen mat man_made=* in OSM
>> > * Wga: vooral de bushokjes en fietsenstallingen zijn interessant
>> > * Wgo: vertaling naar de experimentele area:highway tag? Conversie niet
>> zo
>> > gemakkelijk
>> > * Wti : verkeersplateaus
>> > * Wni: muurtjes en vangrails naast de weg
>> >
>> > De rest komt ofwel niet overeen met OSM (hun wegbaan gebieden nemen ook
>> > delen van voortuinen in, en de wateroppervlaktes nemen ook grote delen
>> vaste
>> > oever in), of heeft geen equivalent in OSM.
>> >
>> > Mvg,
>> > Sander
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


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

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

Re: [OSM-talk-be] GRB open data

2015-12-06 Thread Pieter Colpaert 
Njah... Het probleem is ook wat dat we iedere dag een nieuwe manuele 
downloadprocedure moeten starten ipv gewoon een URI opnieuw te kunnen 
afhalen.


Pieter

On 06-12-15 11:33, joost schouppe wrote:
Torrenten of mirror zou tof zijn, maar die data wordt constant 
bijgewerkt, dus dan krijg je rap een verouderde kopie...



Op 6 december 2015 10:51 schreef Pieter Colpaert 
>:


Zouden we geen mirror kunnen opzetten voor deze data (zijn
tenslotte open data) of deze files torrenten?

Lijkt me beter dan een verschrikkelijk omslachtig
downloadformulier zonder download resuming. Ook al 2 keer proberen
downloaded ondertussen... maar sjah.

Pieter


On 06-12-15 10:48, joost schouppe wrote:

Sander,

Je kan ook laag per laag downloaden: minder kans op miserie.

Misschien zijn de "wegverbindingen" van Agiv wel nuttiger als het
wegenregister: ik denk dat die wegverbindingen volledig zijn voor
hetgeen ze willen doen, terwijl wegenregister dan wel breder is
(ook trage wegen etc.), maar minder volledig.

Op 5 december 2015 13:42 schreef Sander Deryckere
>:

Hmm, net een poging gedaan om het volledige GRB te
downloaden, maar dat is mislukt.

Het volledige GRB is 15.4GB groot. Maar ergens rond 11GB ging
mijn connectie uit voor even. Normaal is dat geen probleem,
en wordt de download automatisch hervat.

Helaas eist Agiv dat je ingelogd bent om het GRB te
downloaden, en werd mijn request naar een inlogpagina
gezonden i.p.v. naar het echte bestand. Het resultaat is: een
nutteloze html pagina in mijn downloads en die 11GB die al
gedownload was is niet meer te vinden.

Dus aan iedereen die de download probeert: doe het met een
stabiele connectie (en zonder pauzes).

Op 4 december 2015 19:23 schreef Marc Gemis
>:

cabine : Electrical, gas or other cabine

kan onder man_made=street_cabinet of misschien
pipeline/power=substation afh. van de grootte

in- of uitrit van een parking : highway=service +
service=parking_aisle

dacht ik ook, maar via de discussie op reddit die ik net
gelezen heb
[1] moet de toegangsweg highway=service zijn. Heb dat
zelf nog nooit
zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en
ik heb die
wiki pagina al lang niet meer bekeken

[1]

https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
[2]
https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle

2015-12-04 18:55 GMT+01:00 Sander Deryckere
>:
> Ik heb geprobeerd de Agiv en OSM data wat te
vergelijken (onderzoeken welke
> definities gebruikt worden in OSM vs Agiv). Mijn
bevindingen staan hier:
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
>
> In het kort, zeker niet alles is bruikbaar. Deze zijn
de meest bruikbare
> bestanden voor OSM:
>
> * Gbg and delen van Gba: de gebouw contouren, gevels
zijn van goede
> kwaliteit (door landmeters opgemeten), in de
achterstukken kunnen soms wat
> fouten zitten
> * Wvb: middellijnen van straten (met naam, type en
andere data), goede
> kwaliteit, ook niet teveel nodes
> * Wgr en Wlas: middellijnen van grachten, beken en
rivieren (met naam),
> goede kwaliteit, zoals wegen
> * Knw: een hoop verschillende zaken die we mappen mat
man_made=* in OSM
> * Wga: vooral de bushokjes en fietsenstallingen zijn
interessant
> * Wgo: vertaling naar de experimentele area:highway
tag? Conversie niet zo
> gemakkelijk
> * Wti : verkeersplateaus
> * Wni: muurtjes en vangrails naast de weg
>
> De rest komt ofwel niet overeen met OSM (hun wegbaan
gebieden nemen ook
> delen van voortuinen in, en de wateroppervlaktes nemen
ook grote delen vaste
> oever in), of heeft geen equivalent in OSM.
>
> Mvg,
> Sander
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org

> https://lists.openstreetmap.org/listinfo/talk-be
>

Re: [OSM-talk-be] GRB open data

2015-12-06 Thread joost schouppe 
Ondertussen een QGIS projectje voor visuele inspectie gemaakt:

http://i.imgur.com/9AgHJDj.jpg

Puur visueel: OSM wegen worden in transparant blauw over rode WVB wegen
gelegd. Dus wat rood is ontbreekt in OSM, wat blauw is ontbreekt in WVB
(dat laatste is 'normaal', aangezien ik niet gefilterd heb op trage wegen).

Lijkt mij een handig werk-instrument, handiger dan geknoei in FME zoals ik
eerst voor ogen had.

Ik dacht een projectje in umap te maken, maar WVB is 300 megabyte in
geoJSON, dat kan die niet aan.

Dus dan maar het QGIS projectje delen? Maar dan zit je weer met het
probleem hoe je de OSM wegen er gemakkelijk en up to date in krijgt. In
umap kan je gewoon linken aan een Overpass-Turbo query, maar zoiets krijg
ik niet aan de praat in QGIS.

Je kan natuurlijk verwijzen naar de shapefiles/pbf files van Geofabrik,
maar dan is het natuurlijk niet live en bovendien liggen ze plat voor het
moment.

Iemand ideeen?


Op 6 december 2015 11:36 schreef Pieter Colpaert :

> Njah... Het probleem is ook wat dat we iedere dag een nieuwe manuele
> downloadprocedure moeten starten ipv gewoon een URI opnieuw te kunnen
> afhalen.
>
> Pieter
>
>
> On 06-12-15 11:33, joost schouppe wrote:
>
> Torrenten of mirror zou tof zijn, maar die data wordt constant bijgewerkt,
> dus dan krijg je rap een verouderde kopie...
>
>
> Op 6 december 2015 10:51 schreef Pieter Colpaert  >:
>
>> Zouden we geen mirror kunnen opzetten voor deze data (zijn tenslotte open
>> data) of deze files torrenten?
>>
>> Lijkt me beter dan een verschrikkelijk omslachtig downloadformulier
>> zonder download resuming. Ook al 2 keer proberen downloaded ondertussen...
>> maar sjah.
>>
>> Pieter
>>
>>
>> On 06-12-15 10:48, joost schouppe wrote:
>>
>> Sander,
>>
>> Je kan ook laag per laag downloaden: minder kans op miserie.
>>
>> Misschien zijn de "wegverbindingen" van Agiv wel nuttiger als het
>> wegenregister: ik denk dat die wegverbindingen volledig zijn voor hetgeen
>> ze willen doen, terwijl wegenregister dan wel breder is (ook trage wegen
>> etc.), maar minder volledig.
>>
>> Op 5 december 2015 13:42 schreef Sander Deryckere < 
>> sander...@gmail.com>:
>>
>>> Hmm, net een poging gedaan om het volledige GRB te downloaden, maar dat
>>> is mislukt.
>>>
>>> Het volledige GRB is 15.4GB groot. Maar ergens rond 11GB ging mijn
>>> connectie uit voor even. Normaal is dat geen probleem, en wordt de download
>>> automatisch hervat.
>>>
>>> Helaas eist Agiv dat je ingelogd bent om het GRB te downloaden, en werd
>>> mijn request naar een inlogpagina gezonden i.p.v. naar het echte bestand.
>>> Het resultaat is: een nutteloze html pagina in mijn downloads en die 11GB
>>> die al gedownload was is niet meer te vinden.
>>>
>>> Dus aan iedereen die de download probeert: doe het met een stabiele
>>> connectie (en zonder pauzes).
>>>
>>> Op 4 december 2015 19:23 schreef Marc Gemis < 
>>> marc.ge...@gmail.com>:
>>>
>>> cabine : Electrical, gas or other cabine

 kan onder man_made=street_cabinet of misschien
 pipeline/power=substation afh. van de grootte

 in- of uitrit van een parking : highway=service + service=parking_aisle

 dacht ik ook, maar via de discussie op reddit die ik net gelezen heb
 [1] moet de toegangsweg highway=service zijn. Heb dat zelf nog nooit
 zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en ik heb die
 wiki pagina al lang niet meer bekeken

 [1]
 https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
 [2] https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle

 2015-12-04 18:55 GMT+01:00 Sander Deryckere < 
 sander...@gmail.com>:
 > Ik heb geprobeerd de Agiv en OSM data wat te vergelijken (onderzoeken
 welke
 > definities gebruikt worden in OSM vs Agiv). Mijn bevindingen staan
 hier:
 > https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
 >
 > In het kort, zeker niet alles is bruikbaar. Deze zijn de meest
 bruikbare
 > bestanden voor OSM:
 >
 > * Gbg and delen van Gba: de gebouw contouren, gevels zijn van goede
 > kwaliteit (door landmeters opgemeten), in de achterstukken kunnen
 soms wat
 > fouten zitten
 > * Wvb: middellijnen van straten (met naam, type en andere data), goede
 > kwaliteit, ook niet teveel nodes
 > * Wgr en Wlas: middellijnen van grachten, beken en rivieren (met
 naam),
 > goede kwaliteit, zoals wegen
 > * Knw: een hoop verschillende zaken die we mappen mat man_made=* in
 OSM
 > * Wga: vooral de bushokjes en fietsenstallingen zijn interessant
 > * Wgo: vertaling naar de experimentele area:highway tag? Conversie
 niet zo
 > gemakkelijk
 > * Wti : verkeersplateaus
 > * Wni: muurtjes en vangrails naast de weg
 >
 > De rest komt ofwel niet overeen met OSM (hun wegbaan gebieden

Re: [OSM-talk-be] GRB open data

2015-12-06 Thread joost schouppe 
Torrenten of mirror zou tof zijn, maar die data wordt constant bijgewerkt,
dus dan krijg je rap een verouderde kopie...


Op 6 december 2015 10:51 schreef Pieter Colpaert :

> Zouden we geen mirror kunnen opzetten voor deze data (zijn tenslotte open
> data) of deze files torrenten?
>
> Lijkt me beter dan een verschrikkelijk omslachtig downloadformulier zonder
> download resuming. Ook al 2 keer proberen downloaded ondertussen... maar
> sjah.
>
> Pieter
>
>
> On 06-12-15 10:48, joost schouppe wrote:
>
> Sander,
>
> Je kan ook laag per laag downloaden: minder kans op miserie.
>
> Misschien zijn de "wegverbindingen" van Agiv wel nuttiger als het
> wegenregister: ik denk dat die wegverbindingen volledig zijn voor hetgeen
> ze willen doen, terwijl wegenregister dan wel breder is (ook trage wegen
> etc.), maar minder volledig.
>
> Op 5 december 2015 13:42 schreef Sander Deryckere :
>
>> Hmm, net een poging gedaan om het volledige GRB te downloaden, maar dat
>> is mislukt.
>>
>> Het volledige GRB is 15.4GB groot. Maar ergens rond 11GB ging mijn
>> connectie uit voor even. Normaal is dat geen probleem, en wordt de download
>> automatisch hervat.
>>
>> Helaas eist Agiv dat je ingelogd bent om het GRB te downloaden, en werd
>> mijn request naar een inlogpagina gezonden i.p.v. naar het echte bestand.
>> Het resultaat is: een nutteloze html pagina in mijn downloads en die 11GB
>> die al gedownload was is niet meer te vinden.
>>
>> Dus aan iedereen die de download probeert: doe het met een stabiele
>> connectie (en zonder pauzes).
>>
>> Op 4 december 2015 19:23 schreef Marc Gemis < 
>> marc.ge...@gmail.com>:
>>
>> cabine : Electrical, gas or other cabine
>>>
>>> kan onder man_made=street_cabinet of misschien
>>> pipeline/power=substation afh. van de grootte
>>>
>>> in- of uitrit van een parking : highway=service + service=parking_aisle
>>>
>>> dacht ik ook, maar via de discussie op reddit die ik net gelezen heb
>>> [1] moet de toegangsweg highway=service zijn. Heb dat zelf nog nooit
>>> zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en ik heb die
>>> wiki pagina al lang niet meer bekeken
>>>
>>> [1]
>>> https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
>>> [2] https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle
>>>
>>> 2015-12-04 18:55 GMT+01:00 Sander Deryckere :
>>> > Ik heb geprobeerd de Agiv en OSM data wat te vergelijken (onderzoeken
>>> welke
>>> > definities gebruikt worden in OSM vs Agiv). Mijn bevindingen staan
>>> hier:
>>> > https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
>>> >
>>> > In het kort, zeker niet alles is bruikbaar. Deze zijn de meest
>>> bruikbare
>>> > bestanden voor OSM:
>>> >
>>> > * Gbg and delen van Gba: de gebouw contouren, gevels zijn van goede
>>> > kwaliteit (door landmeters opgemeten), in de achterstukken kunnen soms
>>> wat
>>> > fouten zitten
>>> > * Wvb: middellijnen van straten (met naam, type en andere data), goede
>>> > kwaliteit, ook niet teveel nodes
>>> > * Wgr en Wlas: middellijnen van grachten, beken en rivieren (met naam),
>>> > goede kwaliteit, zoals wegen
>>> > * Knw: een hoop verschillende zaken die we mappen mat man_made=* in OSM
>>> > * Wga: vooral de bushokjes en fietsenstallingen zijn interessant
>>> > * Wgo: vertaling naar de experimentele area:highway tag? Conversie
>>> niet zo
>>> > gemakkelijk
>>> > * Wti : verkeersplateaus
>>> > * Wni: muurtjes en vangrails naast de weg
>>> >
>>> > De rest komt ofwel niet overeen met OSM (hun wegbaan gebieden nemen ook
>>> > delen van voortuinen in, en de wateroppervlaktes nemen ook grote delen
>>> vaste
>>> > oever in), of heeft geen equivalent in OSM.
>>> >
>>> > Mvg,
>>> > Sander
>>> >
>>> > ___
>>> > Talk-be mailing list
>>> > Talk-be@openstreetmap.org
>>> > https://lists.openstreetmap.org/listinfo/talk-be
>>> >
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
>
> --
> Joost @
> Openstreetmap  |
> Twitter  | LinkedIn
>  | Meetup
>  | Reddit
>  | Wordpress
> 
>
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> -- +32 486 74 71 22
>
> Board of directors
> Open Knowledge Belgiumhttp://openknowledge.be
>
> International Open Transport

Re: [OSM-talk-be] GRB open data

2015-12-05 Thread Sander Deryckere 
Hmm, net een poging gedaan om het volledige GRB te downloaden, maar dat is
mislukt.

Het volledige GRB is 15.4GB groot. Maar ergens rond 11GB ging mijn
connectie uit voor even. Normaal is dat geen probleem, en wordt de download
automatisch hervat.

Helaas eist Agiv dat je ingelogd bent om het GRB te downloaden, en werd
mijn request naar een inlogpagina gezonden i.p.v. naar het echte bestand.
Het resultaat is: een nutteloze html pagina in mijn downloads en die 11GB
die al gedownload was is niet meer te vinden.

Dus aan iedereen die de download probeert: doe het met een stabiele
connectie (en zonder pauzes).

Op 4 december 2015 19:23 schreef Marc Gemis :

> cabine : Electrical, gas or other cabine
>
> kan onder man_made=street_cabinet of misschien
> pipeline/power=substation afh. van de grootte
>
> in- of uitrit van een parking : highway=service + service=parking_aisle
>
> dacht ik ook, maar via de discussie op reddit die ik net gelezen heb
> [1] moet de toegangsweg highway=service zijn. Heb dat zelf nog nooit
> zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en ik heb die
> wiki pagina al lang niet meer bekeken
>
> [1]
> https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
> [2] https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle
>
> 2015-12-04 18:55 GMT+01:00 Sander Deryckere :
> > Ik heb geprobeerd de Agiv en OSM data wat te vergelijken (onderzoeken
> welke
> > definities gebruikt worden in OSM vs Agiv). Mijn bevindingen staan hier:
> > https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
> >
> > In het kort, zeker niet alles is bruikbaar. Deze zijn de meest bruikbare
> > bestanden voor OSM:
> >
> > * Gbg and delen van Gba: de gebouw contouren, gevels zijn van goede
> > kwaliteit (door landmeters opgemeten), in de achterstukken kunnen soms
> wat
> > fouten zitten
> > * Wvb: middellijnen van straten (met naam, type en andere data), goede
> > kwaliteit, ook niet teveel nodes
> > * Wgr en Wlas: middellijnen van grachten, beken en rivieren (met naam),
> > goede kwaliteit, zoals wegen
> > * Knw: een hoop verschillende zaken die we mappen mat man_made=* in OSM
> > * Wga: vooral de bushokjes en fietsenstallingen zijn interessant
> > * Wgo: vertaling naar de experimentele area:highway tag? Conversie niet
> zo
> > gemakkelijk
> > * Wti : verkeersplateaus
> > * Wni: muurtjes en vangrails naast de weg
> >
> > De rest komt ofwel niet overeen met OSM (hun wegbaan gebieden nemen ook
> > delen van voortuinen in, en de wateroppervlaktes nemen ook grote delen
> vaste
> > oever in), of heeft geen equivalent in OSM.
> >
> > Mvg,
> > Sander
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Ben Abelshausen 
2015-12-04 10:13 GMT+00:00 Pieter Colpaert :

> Iemand die er iets mee gaat doen?


Het zal ni lang duren of iemand is er mee weg... ;-)

Zelf nog niets gepland... We kunnen zeker eens een vergelijking doen met
OSM om te beginnen!

Met vriendelijke groeten,
Best regards,

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread joost schouppe 
Ik wil er mijn FME skills wel eens op loslaten. Pakweg: onder welke GRB
gebouwen hebben wij een gebouw liggen. En indien wel, hoeveel verschillen
ze van elkaar. Of onder hoeveel GRB weginrichtingen hebben wij een weg.

Op 4 december 2015 13:06 schreef Ben Abelshausen 
:

> 2015-12-04 10:13 GMT+00:00 Pieter Colpaert :
>
>> Iemand die er iets mee gaat doen?
>
>
> Het zal ni lang duren of iemand is er mee weg... ;-)
>
> Zelf nog niets gepland... We kunnen zeker eens een vergelijking doen met
> OSM om te beginnen!
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


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

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Glenn Plas 
Misschien wel een opmerking, ik ben al enige tijd het GRB aan het
vergelijken (visueel) met OSM, en er zijn wel een aantal plaatsen waar
het GRB letterlijk achterloopt op de feiten.

Vaak is enkel de voorgevel correct maar in de 'diepte' gaat het vaak de
mist in, dus steeds combineren, AGIV+GRB

De accuraatheid hangt sterk van van de verantwoordelijk per gemeente/stad.

Heeft iemand soms een link naar de vector data representatie van het GRB?

Er zijn wel vaak plekken in vlaanderen die bijna totaal geen building
hebben staan, bv : Stekene.

Glenn


On 04-12-15 12:21, joost schouppe wrote:
> Ik wil er mijn FME skills wel eens op loslaten. Pakweg: onder welke GRB
> gebouwen hebben wij een gebouw liggen. En indien wel, hoeveel
> verschillen ze van elkaar. Of onder hoeveel GRB weginrichtingen hebben
> wij een weg.
> 
> Op 4 december 2015 13:06 schreef Ben Abelshausen
> >:
> 
> 2015-12-04 10:13 GMT+00:00 Pieter Colpaert  >:
> 
> Iemand die er iets mee gaat doen?
> 
> 
> Het zal ni lang duren of iemand is er mee weg... ;-)
> 
> Zelf nog niets gepland... We kunnen zeker eens een vergelijking doen
> met OSM om te beginnen!
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> -- 
> Joost @
> Openstreetmap
>  | Twitter
>  | LinkedIn
>  | Meetup
>  | Reddit
>  | Wordpress
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Johan Van de Wauw 
2015-12-04 13:28 GMT+01:00 Glenn Plas :
> Misschien wel een opmerking, ik ben al enige tijd het GRB aan het
> vergelijken (visueel) met OSM, en er zijn wel een aantal plaatsen waar
> het GRB letterlijk achterloopt op de feiten.
>
> Vaak is enkel de voorgevel correct maar in de 'diepte' gaat het vaak de
> mist in, dus steeds combineren, AGIV+GRB
>
Misschien nuttig om te weten: je kan uit de gegevens zien of een punt
al dan niet ingemeten is (laag gvg, gevelpunt). Enkel punten vanop de
straat zichtbaar worden ingemeten. Indien een nieuw gebouw ingemeten
wordt en nog niet aangevuld is met luchtfotodata wordt er gewoon een
standaardafstand van 5m loodrecht op de gevel gebruikt.

Ik wou jullie het voorbeeld van mijn straat laten zien, maar helaas is
dat ondertussen al wel aangevuld op basis van luchtfoto.

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Sander Deryckere 
Op 4 december 2015 13:56 schreef Marc Gemis :

>
> OK, bedankt. Dus als ik GRB als achtergrond gebruik om beekjes te
> tekenen (ipv of in combinatie met de luchtfoto's) zit het wel snor.
>
> m.
>
>
Ja, maar het verschil is dat de GRB nu ook als vector-data beschikbaar is,
dus kan je het bestand downloaden (wel via aanvraag blijkbaar, ik heb net
mijn gemeente aangevraagd, geen idee hoe groot het volledig bestand is), en
dan gewoon copy-pasten (en wat tags aanpassen), of misschien zelfs een nog
meer geautomatiseerde import of QA.

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Marc Gemis 
Ik vraag me af of dat (copy/paste/edit) wel sneller gaat dan
overtekenen en onmiddellijk opletten dat je geen wegen snijdt, of
dubbele beekjes tekent. Hangt ook een beetje af hoe hun representatie
overeenstemt met die van OSM : way voor midden + polygon voor het hele
gebied. Wat voor beekjes en grachten enkel de way is in veel gevallen.

m.

2015-12-04 14:01 GMT+01:00 Sander Deryckere :
>
>
> Op 4 december 2015 13:56 schreef Marc Gemis :
>>
>>
>> OK, bedankt. Dus als ik GRB als achtergrond gebruik om beekjes te
>> tekenen (ipv of in combinatie met de luchtfoto's) zit het wel snor.
>>
>> m.
>>
>
> Ja, maar het verschil is dat de GRB nu ook als vector-data beschikbaar is,
> dus kan je het bestand downloaden (wel via aanvraag blijkbaar, ik heb net
> mijn gemeente aangevraagd, geen idee hoe groot het volledig bestand is), en
> dan gewoon copy-pasten (en wat tags aanpassen), of misschien zelfs een nog
> meer geautomatiseerde import of QA.
>
> Mvg,
> Sander
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Sander Deryckere 
Op 4 december 2015 13:35 schreef Marc Gemis :

> Wat houdt de "Vlaamse Open Data licentie v1.2" feitelijk in ?
>
> Volgens:
> https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/voorwaarden
>
> "De enige gebruiksvoorwaarde is dat je de naam vermeldt van de
> eigenaar van de data bij het doorgeven, bekendmaken of publiceren van
> de gegevens. (zie
>
> https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/bronvermelding)
> ."
>
> en volgens:
>
> https://www.agiv.be/~/media/agiv/producten/data-bestellen-en-downloaden/documenten/gratis%20open%20data%20licentie%20vlaanderen%20v%2012.pdf
>
> Zij is op dergelijke wijze ontworpen dat zij compatibel is met andere
> open licenties die een naamsvermelding als voorwaarde bevatten, zoals
> de Engelse Open Government Licence, de Franse Licence Ouverte, de
> Creative Commons Attribution licentie 3.0 of de Open Data Commons
> Attribution licentie 1.0.
>
> Maar dus geen "SA". Zijn die gegevens dan wel bruikbaar om te traceren ?
>
> Vergelijken zoals Joost wil doen is geen probleem.
>
> m.
>
>
>
De licentie is compatibel met ODBL, dat is voor de CRAB import gechekt. Het
ontbreken van SA wil juist zeggen dat we het naar onze eigen licentie
kunnen brengen (dus ODBL voor OSM, of een andere licentie voor een ander
doel).

En vergelijken is altijd de basis voor importeren ;)

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Marc Gemis 
Wat houdt de "Vlaamse Open Data licentie v1.2" feitelijk in ?

Volgens: 
https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/voorwaarden

"De enige gebruiksvoorwaarde is dat je de naam vermeldt van de
eigenaar van de data bij het doorgeven, bekendmaken of publiceren van
de gegevens. (zie
https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/bronvermelding)."

en volgens:
https://www.agiv.be/~/media/agiv/producten/data-bestellen-en-downloaden/documenten/gratis%20open%20data%20licentie%20vlaanderen%20v%2012.pdf

Zij is op dergelijke wijze ontworpen dat zij compatibel is met andere
open licenties die een naamsvermelding als voorwaarde bevatten, zoals
de Engelse Open Government Licence, de Franse Licence Ouverte, de
Creative Commons Attribution licentie 3.0 of de Open Data Commons
Attribution licentie 1.0.

Maar dus geen "SA". Zijn die gegevens dan wel bruikbaar om te traceren ?

Vergelijken zoals Joost wil doen is geen probleem.

m.


2015-12-04 11:13 GMT+01:00 Pieter Colpaert :
> Dag Vlaamse OSM-ers,
>
> Het grootschalig referentiebestand Vlaanderen is open data:
> https://download.agiv.be/Producten/Detail?id=1=GRBgis
>
> Iemand die er iets mee gaat doen?
>
> Mvg,
>
> Pieter
>
> --
> +32 486 74 71 22
>
> Board of directors
> Open Knowledge Belgium
> http://openknowledge.be
>
> International Open Transport community
> http://transport.okfn.org
>
> Belgian Open Transport community
> http://transport.openknowledge.be
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Marc Gemis 
2015-12-04 13:49 GMT+01:00 Sander Deryckere :
>
>
> Op 4 december 2015 13:35 schreef Marc Gemis :
>>
>> Wat houdt de "Vlaamse Open Data licentie v1.2" feitelijk in ?
>>
>> Volgens:
>> https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/voorwaarden
>>
>> "De enige gebruiksvoorwaarde is dat je de naam vermeldt van de
>> eigenaar van de data bij het doorgeven, bekendmaken of publiceren van
>> de gegevens. (zie
>>
>> https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/bronvermelding)."
>>
>> en volgens:
>>
>> https://www.agiv.be/~/media/agiv/producten/data-bestellen-en-downloaden/documenten/gratis%20open%20data%20licentie%20vlaanderen%20v%2012.pdf
>>
>> Zij is op dergelijke wijze ontworpen dat zij compatibel is met andere
>> open licenties die een naamsvermelding als voorwaarde bevatten, zoals
>> de Engelse Open Government Licence, de Franse Licence Ouverte, de
>> Creative Commons Attribution licentie 3.0 of de Open Data Commons
>> Attribution licentie 1.0.
>>
>> Maar dus geen "SA". Zijn die gegevens dan wel bruikbaar om te traceren ?
>>
>> Vergelijken zoals Joost wil doen is geen probleem.
>>
>> m.
>>
>>
>
> De licentie is compatibel met ODBL, dat is voor de CRAB import gechekt. Het
> ontbreken van SA wil juist zeggen dat we het naar onze eigen licentie kunnen
> brengen (dus ODBL voor OSM, of een andere licentie voor een ander doel).
>
> En vergelijken is altijd de basis voor importeren ;)
>
>

OK, bedankt. Dus als ik GRB als achtergrond gebruik om beekjes te
tekenen (ipv of in combinatie met de luchtfoto's) zit het wel snor.

m.

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

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Sander Deryckere 
Hier kunnen alle verschillende datatypes van het GRB bekeken worden, en kan
je ook kijken welke OSM tags er mee kunnen overeenkomen:
https://www.agiv.be/producten/grb/objectcatalogus/entiteiten

Voor een waterloop lijkt 3m breedte de grens te zijn, alles smaller dan 3m
is een gracht, en heeft dus enkel een middellijn.

Mvg,
Sander

Op 4 december 2015 14:09 schreef Marc Gemis :

> Ik vraag me af of dat (copy/paste/edit) wel sneller gaat dan
> overtekenen en onmiddellijk opletten dat je geen wegen snijdt, of
> dubbele beekjes tekent. Hangt ook een beetje af hoe hun representatie
> overeenstemt met die van OSM : way voor midden + polygon voor het hele
> gebied. Wat voor beekjes en grachten enkel de way is in veel gevallen.
>
> m.
>
> 2015-12-04 14:01 GMT+01:00 Sander Deryckere :
> >
> >
> > Op 4 december 2015 13:56 schreef Marc Gemis :
> >>
> >>
> >> OK, bedankt. Dus als ik GRB als achtergrond gebruik om beekjes te
> >> tekenen (ipv of in combinatie met de luchtfoto's) zit het wel snor.
> >>
> >> m.
> >>
> >
> > Ja, maar het verschil is dat de GRB nu ook als vector-data beschikbaar
> is,
> > dus kan je het bestand downloaden (wel via aanvraag blijkbaar, ik heb net
> > mijn gemeente aangevraagd, geen idee hoe groot het volledig bestand is),
> en
> > dan gewoon copy-pasten (en wat tags aanpassen), of misschien zelfs een
> nog
> > meer geautomatiseerde import of QA.
> >
> > Mvg,
> > Sander
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] GRB open data

2015-12-04 Thread Marc Gemis 
cabine : Electrical, gas or other cabine

kan onder man_made=street_cabinet of misschien
pipeline/power=substation afh. van de grootte

in- of uitrit van een parking : highway=service + service=parking_aisle

dacht ik ook, maar via de discussie op reddit die ik net gelezen heb
[1] moet de toegangsweg highway=service zijn. Heb dat zelf nog nooit
zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en ik heb die
wiki pagina al lang niet meer bekeken

[1] 
https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
[2] https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle

2015-12-04 18:55 GMT+01:00 Sander Deryckere :
> Ik heb geprobeerd de Agiv en OSM data wat te vergelijken (onderzoeken welke
> definities gebruikt worden in OSM vs Agiv). Mijn bevindingen staan hier:
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
>
> In het kort, zeker niet alles is bruikbaar. Deze zijn de meest bruikbare
> bestanden voor OSM:
>
> * Gbg and delen van Gba: de gebouw contouren, gevels zijn van goede
> kwaliteit (door landmeters opgemeten), in de achterstukken kunnen soms wat
> fouten zitten
> * Wvb: middellijnen van straten (met naam, type en andere data), goede
> kwaliteit, ook niet teveel nodes
> * Wgr en Wlas: middellijnen van grachten, beken en rivieren (met naam),
> goede kwaliteit, zoals wegen
> * Knw: een hoop verschillende zaken die we mappen mat man_made=* in OSM
> * Wga: vooral de bushokjes en fietsenstallingen zijn interessant
> * Wgo: vertaling naar de experimentele area:highway tag? Conversie niet zo
> gemakkelijk
> * Wti : verkeersplateaus
> * Wni: muurtjes en vangrails naast de weg
>
> De rest komt ofwel niet overeen met OSM (hun wegbaan gebieden nemen ook
> delen van voortuinen in, en de wateroppervlaktes nemen ook grote delen vaste
> oever in), of heeft geen equivalent in OSM.
>
> Mvg,
> Sander
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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