<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Bij mij werkt alles inmiddels weer
prima. Mogelijk was het probleem aan mezelf te wijten en heb ik
per ongeluk de niet-laatste variant van JOSM opgestart na een
crash eerder gisteravond. Deze variant ging inderdaad niet goed om
met het request vanuit de browser, zoals Sander al eerder
signaleerde.<br>
<br>
Over het intekenen van gebouwen via luchtfoto's. Het gaat mij
inderdaad niet om die dakgoot van enkele centimeters maar om de
perspectiefvertekening; dat gaat over meters. Zowel bij de
luchtfoto van het AGIV als die van Bing geldt dat als als de
betreffende locatie zich relatief ver van de loodlijn van de
satelliet / vliegtuig bevond, er een aanzienlijke vertekening is
(ondanks de orthorectificatie waarbij de vertekeningen door
hoogteverschillen op het grondvlak weggewerkt worden).<br>
<br>
Ik heb even een voorbeeldje gemaakt van een aantal huizen in
Oostende:<a href="http://downloader.aptum.nl/ImageryOffset.jpg">http://downloader.aptum.nl/ImageryOffset.jpg</a>
<title></title>
<meta name="GENERATOR" content="LibreOffice 4.0.3.3 (Windows)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
A:link { so-language: zxx }
--></style>. In het rood aangegeven is de daklijn zoals 'men' (ik in
elk geval) geneigd is in te tekenen. In het blauw de 'correcte'
lijn door rekening te houden met het perspectief (ervan uitgaande
dat de georefererentie 'nauwkeurig' is). Die rode lijn intekenen
is vrij simpel. Die blauwe vind ik pure ellende, met name omdat de
hoekpunten heel vaak verstopt liggen in het perspectief. In dit
geval is de foto van linksonder genomen, aardig in lijn met de
straat, waardoor de perspectiefvervorming hier enkel in de breedte
van de huizen optreedt en niet in de diepte. Dit is dus absoluut
geen extreem geval.<br>
<br>
Omdat de daken niet even hoog komen, lijkt het alsof het ene huis
dieper is dan het andere. Ik ken de situatie ter plaatse en dat is
niet het geval. In dit geval zijn de Bing-beelden meer van
loodrecht boven de locatie genomen. Daarmee is de
perspectiefvertekening veel minder en passen de blauwe lijnen heel
netjes over de daklijnen. Op de GRB-kaart zie je dat de blauwe
lijn heel aardig klopt. Toch zou je op basis van de AGIV-foto het
idee kunnen krijgen dat ze onnauwkeurig ingetekend zijn.<br>
<br>
Het verschil tussen de blauwe en rode lijnen bedraagt in dit geval
ongeveer 2,5m. Enerzijds is dat een beperkte fout, maar anderzijds
kan dat wel voor miserie zorgen bij de CRAB-import. Zoals je op
mijn voorbeeld al kunt zien, lijnen de adrespunten (de kleine
witte cijfertjes) op het verkeerde dak uit. Ze liggen nog net niet
in het naastgelegen rode perceel. In andere situaties kan dat wel
het geval zijn. Wat mij betreft is dit zeker een aandachtspunt in
de workflow, met name bij rijtjeshuizen. Het is ook de reden dat
ik (zeker in mijn omgeving) een hekel heb aan het intekenen van
gebouwen; het is zeer lastig om het enigszins nauwkeurig te doen.<br>
<br>
Als probleem voor de import valt het overigens wel mee. De meeste
bebouwing op OSM in België ontbreekt nog. Daarnaast zijn de
gebouwen die wel ingetekend zijn meestal vrijstaande woningen. De
bestaande problematiek is dus zeker nog te overzien. Het wordt
volgens mij vooral een issue als bij de import van de
CRAB-gegevens massaal ingetekend worden van de AGIV-luchtfoto
zonder met dit effect rekening te houden. Ik twijfel er niet aan
dat er dan heel wat CRAB-punten boven een anders-genummerd
OSM-gebouw komen te vallen. Bij foutcontrole kan dat een probleem
vormen, maar dat hangt natuurlijk af van hoe die controle
ingebouwd wordt.<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Marc Gemis schreef op 23-10-2014 8:29:<br>
</div>
<blockquote
cite="mid:CAJKJX-Sy-UM2tuky8g+OzeqR4Bp9W3QCxaZFp9WvbJyxQWsgmw@mail.gmail.com"
type="cite">
<div dir="ltr">Een allegaartje van antwoorden en opmerkingen:
<div><br>
</div>
<div>- Ja, dit is een import (je kopieert data van een andere
databank zonder survey) en dus moet je voldoen aan de import
procedure. Deze moet dus beschreven worden en voorgelegd
worden aan de import lijst. Een van de voorwaarden is een
specifieke account..Je mag dus nu feitelijk nog geen data
overnemen via de tool, omdat de procedure nog niet is
goedgekeurd. Ik vraag me wel af in hoeverre deze werkwijze
tegemoet komt aan de vragen/eisen die er met de vorige manier
opdoken.</div>
<div>- Ik heb Chrome gebruikt (te lui om ook Firefox te
installeren) en hoopte dat dat ook zou werken. Sander, Welke
vieze trucks heb je gebruikt omdat het enkel op Firefox zou
werken ? (grapje :-) Eerst met 2840 (Rumst), daarna met de
A-straten (10 of zo), dan met 1 straat. Kreeg geen resultaat.
Zal later nog wel eens met Firefox proberen</div>
<div>- Als je geen initiële survey doet, hoe weet je dan of de
nummers in AGIV Crab juist zijn ? Ik wil daar niet vanuit
gaan, heb al een paar problemen gezien. Ook ontbreken er soms
nummer (niet alleen nieuwbouw). Als je nu de nummers gewoon
overneemt, zonder controle, gaan die fouten er maar heel
langzaam uitgaan. Waar geven we de voorkeur aan: geen data of
data met ?? fouten. Ik heb er nog steeds geen zicht op hoe
goed AGIV Crab is. 5% fouten ? meer ? minder ? Dit is volgens
mij een van de vragen van de import mailing list.</div>
<div>- Het kadaster is volgens mij niet rechtsgeldig (zie bv <a
moz-do-not-send="true"
href="http://bouwinfo.be/forum/threads/136644-buurman-zet-afsluiting-1-5m-over-de-scheidingslijn/page2">http://bouwinfo.be/forum/threads/136644-buurman-zet-afsluiting-1-5m-over-de-scheidingslijn/page2</a>
)</div>
<div>- Het is nu de bedoeling dat de gemeenten de huizen gaan
intekenen (meen ik begrepen te hebben van Gilbert). Volgens
zijn "contact" persoon tekenen zij ook de huizen in vanaf de
luchtfoto's. Moeten we daar niet nog eens contacten leggen,
een presentatie geven ?</div>
<div>- Waarvoor wil je de gegevens van de gebouwen tekenen ? Hoe
groot mag de foutenmarge zijn ? Een dakgoot is volgens mij
niet meer dan 1 of 2 pixels. Wat is het fouten percentage als
je die volgt ? Het perspectief geeft een grotere fout. Ik wil
best meewerken aan de beste kaart, maar gaat het volgen van de
dakgoot de kwaliteit van de kaart zodanig naar beneden halen
dat ze niet meer bruikbaar is voor je toepassing ?</div>
<div>- Wat is het nut om een huisnummer op de voordeur van een
privé woning te zetten ? Voor deur naar deur routering voor
slechtzienden ? Maar dan moet het ook wel echt juist zijn. Een
meter of 2 naar rechts of links helpt dan ook niet. Bij grote
gebouwen (bedrijven, of evenementshallen) kan ik er nog
inkomen, maar dan moet je ook entrance=... erbij zetten. Een
huisnummer bij de deur plaatsen is enkel nodig indien er
verschillende huisnummers in een gebouw zijn met elk een eigen
ingang. En dat kan je enkel weten door een survey.</div>
<div>- Zijn huisnummers niet belangrijker voor autonavigatie dan
de gebouwen ?</div>
<div><br>
</div>
<div>- oh ja, ook nog een +1 voor Glenn's antwoord i.vm. met al
dan niet overtekenen van GRB kaart, de mogelijke easter eggs
en zijn standpunt dat als alles correct is de 2 kaarten toch
gelijk zouden moeten zijn. </div>
<div><br>
</div>
<div>met vriendelijke groeten</div>
<div><br>
</div>
<div>m</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-10-23 0:15 GMT+02:00 Thomas <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Ik heb nu de laatste variant van de website van
Sander even snel uitgeprobeerd; een dikke twee uur
geleden werkte alles prima, maar het laatste uur krijg
ik steeds een 400: bad-request van JOSM terug op het
request vanaf het js-script, met daarbij “no command
specified” (ongeacht welke van de 4 sets per straat ik
gebruik). OSM-data inladen via de straatnaam werkt
perfect. Het vergelijk met OSM werkt wel perfect, alleen
het inladen in JOSM gaat dus fout. Wissen van de cache
heeft geen effect (Firefox 33).<br>
<br>
Uit een aantal snelle eerste vergelijkingen lijken in
mijn regio (Oostende) vrijwel alle adresposities zéér
mooi uit te lijnen op het midden van de gebouwen op de
AGIV-luchtfoto. Alle reeds gemaakte opmerkingen over
afwijkende positionering zal volgens mij vooral gelden
voor de meer plattelandsgemeenten. Ik moet het nog even
goed bekijken. In elk geval voor de woonwijken in
Oostende zou ik de adrespunten zeer vlot kunnen
verwerken en als punt importeren, als we het eens zouden
zijn dat dat de nu de beste aanpak is.<br>
<br>
Ik ben het zeker eens met het feit dat de
gebouw-contouren hebben veel 'rijker' is voor de kaart
dan puur de adrespositie. Toch vind ik dat die
adrespositie op zichzelf waarde heeft. Volgens alle
richtlijnen van OSM zijn adrespunten, naar mijn idee,
zeker de moeite waard, ook al zijn de bijbehorende
gebouwen nog niet ingetekend. Dat die gebouwen eigenlijk
belangrijker zijn dan de nummers vind ik een terechte
opmerking, maar we hebben niet de beschikking over die
gegevens. Daarnaast blijf ik bij mijn eerdere standpunt
dat alle gebouwen intekenen zeer veel werk is, vrij
onnauwkeurig door perspectiefvertekening en
schaduwwerking en buitengewoon frustrerend als over een
paar maand de GRB-data alsnog open zou worden. Ikzelf
zie heel vaak af van het intekenen van gebouwen vanaf de
luchtfoto omwille van bovenstaande redenen. In mijn
werkomgeving ben ik ook vaak bezig met data-entry in
GIS-systemen. Ik vind het zeer frustrerend om zo
onnauwkeurig te werken als bij het intekenen van
gebouwen vanaf een luchtfoto.<br>
<br>
Daartegenover moet ik zeggen dat ik de GRB-data in mijn
regio volgens mij extreem nauwkeurig is (los van
tijdsdiscrepanties). Volgens mij is die data afkomstig
van het kadaster. De moderne gegevens zijn met
professionele GPS ingemeten, de oudste volgens mij zijn
gedigitaliseerd van de analoge kaarten.
Kadaster-gegevens hebben een bijzondere 'rechtspositie'.
Volgens mij hangen de licentie-problemen daar mee samen.
De 'eigendom' van die gegevens is een zeer complexe
zaak. De oorspronkelijke data stamt formeel uit het
begin van de 19de eeuw en is daarmee auteursrechtenvrij.
De oorspronkelijke kaarten (ondermeer uitgegeven door
Popp en raadpleegbaar op <a moz-do-not-send="true"
href="http://geopunt.be" target="_blank">geopunt.be</a>)
zijn op zich auteursrechtenvrij maar de scans zijn dat
niet. De huidige kadastrale systemen zijn een directe
voortzetting van dat historische systeem. Hoe en wat
precies met rechten op de data is buitengewoon complex.<br>
<br>
Over de workflow: ik vind dat de adrespunten op zichzelf
geïmporteerd mogen worden; ook bij afwezigheid van het
gebouw. Uiteraard moeten de punten wel handmatig 1 voor
1 gecontroleerd worden met de AGIV-luchtfoto. Een
automatische datapomp is een echte no-go, maar daar
lijken we het allemaal over eens te zijn. Wanneer de
situatie niet duidelijk is, kan nog een beroep gedaan
worden op de GRB-gegevens (zonder de contouren over te
nemen!) of bij aanhoudende onduidelijkheid kan survey
ter plaatse noodzakelijk zijn en/of moet van import van
de specifieke punt uiteraard afgezien worden. Wanneer
het gebouw aanwezig is (een relatieve zeldzaamheid, heb
ik het idee) mogen wat mij betreft de adresgegevens op
het gebouw getagd worden en mag het punt verwijderd
worden. Dat er dan adressen op gebouwen staan en
anderzijds adressen op punten lijkt mij geen probleem.
Uit mijn eerste testen besluit ik dat ik met deze
werkwijze zeer vlot een regio kan verwerken, zonder
onzin-data te importeren. Het aantal “moeilijke
gevallen” is in mijn regio zeer beperkt. Dat kan
uiteraard per regio verschillen.<br>
<br>
Over Bing versus AGIV: Bing zal altijd bekender zijn dan
AGIV. Hoe eenvoudig het ook wordt om de AGIV-luchtfoto
te gebruiken: als 'startende OSM-editende leden' ook
voor Bing kunnen kiezen zullen ze dat heel snel doen.
Dit als belangrijk punt naar voor schuiven in de
'how-to-get-started'-lijstjes lijkt mij enkel de drempel
te verhogen. Het is volgens mij belangrijker om de
aandacht te vestigen op de onnauwkeurigheid van
luchtofotografie in het algemeen. De misvattingen over
schaduwen, perspectief etc. zorgen voor een verkeerde
interpretatie van de luchtfoto en bijgevolg het verkeerd
aanpassen / corrigeren van wél correct ingevoerde
gegevens. Het klopt dat de voetafdruk van een gebouw
haast nooit netjes uitlijnt met de dakgoot-contour. Die
contour is echter wél heel duidelijk zichtbaar op de
luchtfoto. Het is een natuurlijke reflex om een
gebouw-contour te tekenen rond die dakgoot, maar daarmee
nog niet minder fout. Ik ben het wel volledig eens met
het verder promoten van de AGIV-luchtfoto voor
Vlaanderen.<br>
<br>
Voor wat betreft de workflow van het importeren van de
adressen kom ik nu tot volgende richtlijnen:<br>
– In de basis altijd het gebouw de adres-tags meegeven.
In principe geen losse adres-nodes, tenzij:<br>
* gebouw nog niet ingetekend maar wel aanwezig op
luchtfoto:<br>
→ gebouw intekenen en adres-tags toevoegen OF
punt midden boven gebouw plaatsen.<br>
* gebouw nog niet ingetekend en niet zichtbaar op
luchtfoto maar wel gezien bij survey:<br>
→ adres-punt op gesurveyde locatie plaatsen<br>
– Wanneer er meerdere adressen binnen 1 gebouw zijn:<br>
→ gezamenlijke kenmerken op gebouw taggen, al de
rest op de individuele adres-nodes (“Nederlands
systeem”)<br>
– Wanneer er meerdere adressen zich precies boven elkaar
bevinden:<br>
→ de adressen individueel registreren als punt, maar
de punten mogen niet op elkaar vallen.<br>
– Over het hoe en wat voor adrespunten zonder locatie
zal het vooronderzoek eerst duidelijkheid moeten brengen<br>
<br>
Over de precieze locatie van de adres-nodes kan
gediscussieerd worden. Zoals Sander voorstelt (het punt
op de ingang plaatsen) is het in veel gevallen logisch.
In veel andere gevallen is het volgens mij lastig om de
ingang precies aan te wijzen, zonder survey. Ik vrees
dat in de praktijk veel nodes toch lukraak op het gebouw
zullen belanden. De richtlijn om het punt op de ingang
te plaatsen is dan misschien enkel verwarrend, wanneer
het niet consequent toegepast wordt. Maar daar zijn vast
ook heel andere meningen over...<br>
<br>
Bij de vorige stap naar de import-lijst was er discussie
over het al dan niet gebruiken van een dedicated
account. Is er consensus over hoe hiermee om te gaan? Of
is het een kwestie waar we het niet over hoeven te
hebben en gewoon 'de regels' volgen en de import met een
dedicated account uitvoeren?<br>
<br>
Is er verder nu ook consensus over het feit dat de twee
tags (huisnummer en straatnaam) op de node of het gebouw
getagd worden in tegenstelling tot het koppelen van alle
huisnummers aan de straat met een relatie?<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 22-10-2014 21:40:<br>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 22 oktober 2014
20:57 schreef Marc Gemis <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:marc.gemis@gmail.com"
target="_blank">marc.gemis@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">Sander, (& anderen)
<div><br>
</div>
<div>ik heb je website daarstraks eens
geprobeerd. Jammer genoeg kreeg ik niets
anders dan "Loading". Niet lang genoeg
gewacht ? Server overladen ? Verkeerde
browser ?</div>
<div><br>
</div>
</div>
</blockquote>
<div>Welke browser? Welke postcode (misschien
een grote stad waarbij het niet werkt)? Heb
je het net nog geprobeerd (mogelijks moet je
de browser cache legen om de verbeterde
versie van het JS script opnieuw te
downloaden)?<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Ik vraag me nu af hoe ik een en ander
in mijn workflow kan inpassen.</div>
</div>
</blockquote>
<div> </div>
<div>Ik ook :D Dat vraagt natuurlijk wat
onderzoek en wat denkwerk. <br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Het overzicht van wat er al in OSM
zit is heel handig, maar dan zou het
resultaat onmiddellijk zichtbaar moeten
zijn. Zou dit kunnen door het script 's
nachts te laten lopen en de resultaten
te cachen in een DB ? (sorry maar hier
komt mijn achtergrond naar boven :-) ).</div>
</div>
</blockquote>
<div> </div>
<div>Niet met de huidige code. Alles gebeurt
client-side, wat maakt dat het (eenmaal de
kinderziekten verdwenen zijn) bijna geen
onderhoud zal vragen. Als je werkt met een
DB, dan moet er altijd server infrastructuur
onderhouden worden, waardoor er kostbare
mapping tijd verloren gaat.<br>
<br>
</div>
<div>Ik denk ook dat niet in elke gemeente
elke dag gemapt zal worden. Dus is het
jammer om elke dag alle adressen te
downloaden, wanneer er misschien hoogstens
in 20 gemeenten per dag a.d.h.v. CRAB data
gemapt wordt. <br>
<br>
</div>
<div>Een ander voordeel van live-queries is
dat binnen enkele minuten na het uploaden
naar OSM je al het resultaat zou moeten
zien. Dus kan je eenvoudig straat per straat
mappen, zonder dat je er de volgende dag op
moet terug komen om te kijken als je geen
fouten gemaakt hebt.<br>
</div>
<div><br>
</div>
<div>Normaal is het laden van de data snel
genoeg, en ik kan de overpass query nog wat
verbeteren om het laden nog sneller te maken
(en zal dat zeker doen).<br>
<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>De adrespunten in JOSM overnemen, is
handig, maar gaat het mij tijdwinst
opleveren (gesteld dat ik nog steeds
eerst een survey doe) ? Ik vrees ervoor.
Ik heb al eens gewerkt met de osmose
site vorig jaar en dat ging niet
sneller. Als we de adressen niet op de
gebouwen zouden plaatsen zou er wel een
snelheidswinst inzitten. Dit is een
beetje zoals ze het in Nederland doen.
Hoewel je dan in sommige gevallen toch
nog het adres op het gebouw moet
plaatsen, bv. bij supermarkten waar de
POI gegevens op het gebouw gezet worden.</div>
<div><br>
</div>
</div>
</blockquote>
<div>Ik kan niet meer data aanbieden dan we
van AGIV krijgen ;)<br>
<br>
</div>
<div>Ik weet ook niet als het sneller zal
gaan, maar ik denk dat met de CRAB data
slechts onvolledige surveys zouden nodig
zijn.<br>
<br>
Door een routine te creëren zal je zien waar
er problemen kunnen zijn met de CRAB data
(zeker al met de punten die geen positie
hebben), en specifiek die probleemplaatsen
gaan opzoeken. Ik denk, als je begint met
een volledige survey, zonder CRAB data, dan
kom je thuis, zie je dat er op sommige
plaatsen nog onduidelijkheden zijn, en moet
je nog eens terug. Deze eerste survey zou
kunnen vermeden worden door eerst de
duidelijke CRAB data te importeren.<br>
<br>
</div>
<div>Een andere tool die we kunnen gebruiken
(weet niet als deze al bestaat), is een tool
om "probleemplaatsen" te markeren. Een soort
geografische TODO lijst. Ofwel gedeeld of
persoonlijk. Zodat we aan de computer,
tijdens de initiële CRAB import, deze
probleemplaatsen eenvoudig kunnen markeren
en vergeten, om dan later alle plaatsen te
gaan bezoeken.<br>
<br>
</div>
<div>Deze tool is moeilijker te maken, omdat
het afhangt van de mapping voorkeuren
(mappen op papier, met Android, met iPhone,
...). Dus hoop ik dat er al ergens een
bruikbaar systeem bestaat dat we gewoon
kunnen gebruiken.<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Ik had de indruk dat Sus ongeveer
hetzelfde schreef. een huisnummer
toevoegen in JOSM is 2 kliks
(HouseNumberTool plugin CMD-K/CTRL-K of
terracer-tool).</div>
<div><br>
</div>
</div>
</blockquote>
<div>Daarom laat ik het downloaden als extra
layer. Dan kan je die (met een aangepast
stylesheet) ook als achtergrondlaag
gebruiken, en zelf je eigen gegevens
ingeven. Na het mappen is de laag eenvoudig
te verwijderen. Daarnaast blijft mijn tool
nuttig als controle na het mappen.<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><br>
<div dir="ltr">
<div>Hoe zien jullie dat ? Hoe kunnen we
het harde werk van Sander het beste
gebruiken ?</div>
<div><br>
</div>
<div>met vriendelijke groeten</div>
<span></span></div>
</blockquote>
<div><br>
</div>
<div>Opmerkingen zijn altijd welkom.<br>
<br>
</div>
<div>Groeten,<br>
</div>
<div>Sander <br>
</div>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<span class="">
<pre>_______________________________________________
Talk-be mailing list
<a moz-do-not-send="true" href="mailto:Talk-be@openstreetmap.org" target="_blank">Talk-be@openstreetmap.org</a>
<a moz-do-not-send="true" href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</span></blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Talk-be mailing list<br>
<a moz-do-not-send="true"
href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a moz-do-not-send="true"
href="https://lists.openstreetmap.org/listinfo/talk-be"
target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-be mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-be">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</blockquote>
<br>
</body>
</html>