[OSM-talk-be] Import of 2000 DAE in Belgium (Defibrillators / Défibrillateurs)

[Bruno Veyckemans]

[EN]
Hello,

The "Ligue Cardiologique Belge / Belgische Cardiologische Liga" just issued
a set of 2000 defibrillators (DAE) in Belgium in the Brussels open datastore
http://opendatastore.brussels/en/organization/liguecardioliga (csv or xls)

It would be great to import them in OSM... There are now only 119 DAE known
by OSM for the whole country.

It seems fairly easy (only nodes, no ways) but I don't know how to do it...
What's the best option to merge and import the 119 existing DAE and the
2000 DAE from the Ligue ?

I suppose it has already been done for other data... If you can teach me or
help me to do it, we could add the missing DAE and really help people
looking for a defibrillator in case of emergency.

If it works, the next step will be to the same for bpost's red mailboxes
(amenity=post_box). I know bpost is ready to import its data to OSM (with
collection times and their internal id) but need help to merge it with the
existing mailboxes.

[FR]
Bonjour,
La Ligue Cardiologique Belge vient de publier sa liste de 2000
défibrillateurs (DAE) en Belgique via l'Open Data store de la Région
bruxelloise ici:
http://opendatastore.brussels/en/organization/liguecardioliga (csv ou xls)

Ce serait super de pouvoir les importer dans OSM... qui ne connaît pour
l'instant que 119 DAE pour toute la Belgique (recherche via
http://overpass-turbo.eu/).

Cela semble assez facile vu que ce ne sont que des points (nodes), mais je
ne sais pas trop comment m'y prendre. Quelle est la meilleure option pour
fusionner les 119 DAE existants avec ces 2000 là ? J'imagine que ça a déjà
été fait avec d'autres données... Si vous pouviez m'aider à le faire, ce
serait top et je pense qu'on pourrait faire quelque chose de très utile
pour aiguiller les gens vers le défibrillateur le plus proche en cas
d'urgence. Et ce sera moins décourageant de mettre à jour une liste de 2000
DAE que la liste actuelle, très peu fournie.

Par ailleurs, si ça fonctionne, le travail suivant sera de réaliser un
import similaire avec les boîtes postales rouges de bpost... Je sais qu'ils
sont d'accord pour importer leurs données sur OSM, avec heures de levée et
les id internes de leurs boîtes, ce qui permettra une mise à jour aisée.
Mais il leur manque le savoir-faire pour réaliser l'opération proprement
sur OSM (essentiellement la gestion des boîtes déjà encodées).

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

[OSM-talk-be] municipal boundaries in Belgium

[joost schouppe]

Hi,

I got a question about municipal boundaries in Belgium. I had a look here
[1], but it seems to be lacking detailed information about how this data
was added to OSM and what the source is. I do remember seeing some info
about this, but we should probably have a bit more formal documentation,
right? Or am I missing the right place to look for the info?

1: http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
-- 
joost schouppe
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] municipal boundaries in Belgium

[Killian De Volder]

Personally for Flanders I wouldn't worry to much. Lets wait maybe a a year or 2 
to get the municipals time to correct/update their borders in AGIV (GRB).
But form the things I compared, I found the current borders to be are rather 
good.

I'm going to assume they are rather old too. As such they have probably been 
created using: maps obtained from various sources, signposts, ...

Some-one else might be able to shed more light on this.

On 01-06-16 12:36, joost schouppe wrote:
> Hi,
> 
> I got a question about municipal boundaries in Belgium. I had a look here 
> [1], but it seems to be lacking detailed information about how this data was 
> added to OSM and what the source is. I do remember seeing some info about 
> this, but we should probably have a bit more formal documentation, right? Or 
> am I missing the right place to look for the info?
> 
> 1: http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
> -- 
> joost schouppe
> 
> 
> ___
> 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] municipal boundaries in Belgium

[Sander Deryckere]

Heel wat van de grenzen zijn gemapt door Marc De Ridder (die jammer genoeg
te vroeg van ons heengegaan is:
https://lists.openstreetmap.org/pipermail/talk-be/2013-January/003565.html
).

Zelf heb ik ook de grenzen leren mappen van Marc, en heb ik een groot deel
van de West-Vlaamse grenzen gemapt. De techniek was om out-of-copyright
kaarten te nemen (bijvoorbeeld Popp kaarten), die te aligneren met
weglayouts (want luchtfoto's waren nog niet beschikbaar), om zo ongeveer
correcte grenzen te bekomen.

Het belangrijkste bij die grenzen was om geocoding mogelijk te maken, en
voor het grootste deel van de straten de correcte gemeente te kunnen geven.

Er zitten natuurlijk fouten in (zoals offsets doordat we die kaarten niet
precies genoeg konden aligneren), maar het is niet zo moeilijk om die met
de huidige data te corrigeren (het moeilijkste is de fouten vinden).

Mvg,
Sander

2016-06-01 13:57 GMT+02:00 Killian De Volder :

> Personally for Flanders I wouldn't worry to much. Lets wait maybe a a year
> or 2 to get the municipals time to correct/update their borders in AGIV
> (GRB).
> But form the things I compared, I found the current borders to be are
> rather good.
>
> I'm going to assume they are rather old too. As such they have probably
> been created using: maps obtained from various sources, signposts, ...
>
> Some-one else might be able to shed more light on this.
>
> On 01-06-16 12:36, joost schouppe wrote:
> > Hi,
> >
> > I got a question about municipal boundaries in Belgium. I had a look
> here [1], but it seems to be lacking detailed information about how this
> data was added to OSM and what the source is. I do remember seeing some
> info about this, but we should probably have a bit more formal
> documentation, right? Or am I missing the right place to look for the info?
> >
> > 1: http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
> > --
> > joost schouppe
> >
> >
> > ___
> > 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] municipal boundaries in Belgium

[joost schouppe]

RIP Marc.

So I understand the geometry of the municipal boundaries could be vastly
improved.

I'm guessing the easiest workflow would be to load just the geometry of the
municipalities and just the OSM municipalities in JOSM, then merge the
nodes of the OSM municipalities to the external data. Afterwards, just
discard the external geometry. Right?

I think I could quite easily identify the largest differences with FME to
help set priorities. But I would think this is something where we would
just want to copy the official dataset node for node, no?

2016-06-01 15:18 GMT+02:00 Sander Deryckere :

> Heel wat van de grenzen zijn gemapt door Marc De Ridder (die jammer genoeg
> te vroeg van ons heengegaan is:
> https://lists.openstreetmap.org/pipermail/talk-be/2013-January/003565.html
> ).
>
> Zelf heb ik ook de grenzen leren mappen van Marc, en heb ik een groot deel
> van de West-Vlaamse grenzen gemapt. De techniek was om out-of-copyright
> kaarten te nemen (bijvoorbeeld Popp kaarten), die te aligneren met
> weglayouts (want luchtfoto's waren nog niet beschikbaar), om zo ongeveer
> correcte grenzen te bekomen.
>
> Het belangrijkste bij die grenzen was om geocoding mogelijk te maken, en
> voor het grootste deel van de straten de correcte gemeente te kunnen geven.
>
> Er zitten natuurlijk fouten in (zoals offsets doordat we die kaarten niet
> precies genoeg konden aligneren), maar het is niet zo moeilijk om die met
> de huidige data te corrigeren (het moeilijkste is de fouten vinden).
>
> Mvg,
> Sander
>
> 2016-06-01 13:57 GMT+02:00 Killian De Volder :
>
>> Personally for Flanders I wouldn't worry to much. Lets wait maybe a a
>> year or 2 to get the municipals time to correct/update their borders in
>> AGIV (GRB).
>> But form the things I compared, I found the current borders to be are
>> rather good.
>>
>> I'm going to assume they are rather old too. As such they have probably
>> been created using: maps obtained from various sources, signposts, ...
>>
>> Some-one else might be able to shed more light on this.
>>
>> On 01-06-16 12:36, joost schouppe wrote:
>> > Hi,
>> >
>> > I got a question about municipal boundaries in Belgium. I had a look
>> here [1], but it seems to be lacking detailed information about how this
>> data was added to OSM and what the source is. I do remember seeing some
>> info about this, but we should probably have a bit more formal
>> documentation, right? Or am I missing the right place to look for the info?
>> >
>> > 1: http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
>> > --
>> > joost schouppe
>> >
>> >
>> > ___
>> > 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

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

Re: [OSM-talk-be] Import of 2000 DAE in Belgium (Defibrillators / Défibrillateurs)

[Glenn Plas]

Hi,

It would be a fairly trivial task, don't think we need import approval
from upstream for a few thousand single nodes.  It would be a bit like
importing VELO nodes (bike sharing).  The license of this DAE data is open.

I've made a quality assessment tool to compair VELO nodes from VELO
website (json call/feed) to their OSM counterparts to help reposition
nodes and assess the quality.  From time to time I verify them.  The
tool creates an OSM changefile in case some are missing which you can
open in JOSM and upload.

But aftercare is equally important, so from time to time, I compair this
list to OSM.  It will measure distances, tag differences etc. and notify
when they are seperated too much or where key/values deviate.

Since it's json based and the DAE list isn't (csv) I could modify the
code to support csv data, make it a bit more general.  It uses OverPass
API to compair.  It works with existing nodes.

I write command line tools , hence I usually don't release these as they
aren't really usefull unless you are a command line junkie like myself.
 But I can open this up at will.

VELO is a bit different than this as they -so far- use structured naming
schema which we reference in OSM and this makes it easy to diff the data.

I probably need to change / remove / adapt a few checks but it would
take only a few hours to do so.

in short: I can do this rather quickly.

If somebody believes we should walk the 'import data scenario case'
instead, it will probably take much much longer to complete it.  But I
don't see why we should given the nature of this upload.

Hope this helps,

Glenn



On 01-06-16 11:59, Bruno Veyckemans wrote:
> [EN]
> Hello,
> 
> The "Ligue Cardiologique Belge / Belgische Cardiologische Liga" just
> issued a set of 2000 defibrillators (DAE) in Belgium in the Brussels
> open datastore
> http://opendatastore.brussels/en/organization/liguecardioliga (csv or xls)
> 
> It would be great to import them in OSM... There are now only 119 DAE
> known by OSM for the whole country.
> 
> It seems fairly easy (only nodes, no ways) but I don't know how to do
> it... What's the best option to merge and import the 119 existing DAE
> and the 2000 DAE from the Ligue ?
> 
> I suppose it has already been done for other data... If you can teach me
> or help me to do it, we could add the missing DAE and really help people
> looking for a defibrillator in case of emergency.
> 
> If it works, the next step will be to the same for bpost's red mailboxes
> (amenity=post_box). I know bpost is ready to import its data to OSM
> (with collection times and their internal id) but need help to merge it
> with the existing mailboxes.
> 
> [FR]
> Bonjour,
> La Ligue Cardiologique Belge vient de publier sa liste de 2000
> défibrillateurs (DAE) en Belgique via l'Open Data store de la Région
> bruxelloise ici:
> http://opendatastore.brussels/en/organization/liguecardioliga (csv ou xls)
> 
> Ce serait super de pouvoir les importer dans OSM... qui ne connaît pour
> l'instant que 119 DAE pour toute la Belgique (recherche via
> http://overpass-turbo.eu/).
> 
> Cela semble assez facile vu que ce ne sont que des points (nodes), mais
> je ne sais pas trop comment m'y prendre. Quelle est la meilleure option
> pour fusionner les 119 DAE existants avec ces 2000 là ? J'imagine que ça
> a déjà été fait avec d'autres données... Si vous pouviez m'aider à le
> faire, ce serait top et je pense qu'on pourrait faire quelque chose de
> très utile pour aiguiller les gens vers le défibrillateur le plus proche
> en cas d'urgence. Et ce sera moins décourageant de mettre à jour une
> liste de 2000 DAE que la liste actuelle, très peu fournie.
> 
> Par ailleurs, si ça fonctionne, le travail suivant sera de réaliser un
> import similaire avec les boîtes postales rouges de bpost... Je sais
> qu'ils sont d'accord pour importer leurs données sur OSM, avec heures de
> levée et les id internes de leurs boîtes, ce qui permettra une mise à
> jour aisée. Mais il leur manque le savoir-faire pour réaliser
> l'opération proprement sur OSM (essentiellement la gestion des boîtes
> déjà encodées).
> 
> Merci !
> Bruno
> 
> 
> ___
> 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] municipal boundaries in Belgium

[Glenn Plas]

Hi,

I'm not sure they can be vastly improved, it probably depends a lot on
what boundary.

In that understanding that there is lot's of stuff attached to those
boundaries that shouldn't be there.  So when you are working to improve
boundaries, you'll need to address plenty of those cases, and that will
slow you down (a lot) and prevent more automated fixes.

One could also just go in and unglue all stuff that needs to be as a
preparation and work with clean -closed way- borders, no crap attached.
 That would open the road for 'program-assisted' changes.

Little example: http://overpass-turbo.eu/s/gz0

node 1712080972 : amenity attached to the border

Greets,

Glenn

On 01-06-16 15:46, joost schouppe wrote:
> RIP Marc.
> 
> So I understand the geometry of the municipal boundaries could be vastly
> improved.
> 
> I'm guessing the easiest workflow would be to load just the geometry of
> the municipalities and just the OSM municipalities in JOSM, then merge
> the nodes of the OSM municipalities to the external data. Afterwards,
> just discard the external geometry. Right?
> 
> I think I could quite easily identify the largest differences with FME
> to help set priorities. But I would think this is something where we
> would just want to copy the official dataset node for node, no?
> 

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

Re: [OSM-talk-be] municipal boundaries in Belgium

[joost schouppe]

Well, it depends on your definition of vastly :)
(I haven't looked at the size of the differences yet)

I was talking about municipal borders (admin_level=8), postal codes as in
your example are a wholly different beast, one I wouldn't want to tackle
right now.
But yes, they have a lot of things sticking to them too.

So when is our next hackathon to work on things like this?


2016-06-01 16:00 GMT+02:00 Glenn Plas :

> Hi,
>
> I'm not sure they can be vastly improved, it probably depends a lot on
> what boundary.
>
> In that understanding that there is lot's of stuff attached to those
> boundaries that shouldn't be there.  So when you are working to improve
> boundaries, you'll need to address plenty of those cases, and that will
> slow you down (a lot) and prevent more automated fixes.
>
> One could also just go in and unglue all stuff that needs to be as a
> preparation and work with clean -closed way- borders, no crap attached.
>  That would open the road for 'program-assisted' changes.
>
> Little example: http://overpass-turbo.eu/s/gz0
>
> node 1712080972 : amenity attached to the border
>
> Greets,
>
> Glenn
>
> On 01-06-16 15:46, joost schouppe wrote:
> > RIP Marc.
> >
> > So I understand the geometry of the municipal boundaries could be vastly
> > improved.
> >
> > I'm guessing the easiest workflow would be to load just the geometry of
> > the municipalities and just the OSM municipalities in JOSM, then merge
> > the nodes of the OSM municipalities to the external data. Afterwards,
> > just discard the external geometry. Right?
> >
> > I think I could quite easily identify the largest differences with FME
> > to help set priorities. But I would think this is something where we
> > would just want to copy the official dataset node for node, no?
> >
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>



-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk-be] municipal boundaries in Belgium

[Glenn Plas]

Hey Joost,

On 01-06-16 16:19, joost schouppe wrote:
> Well, it depends on your definition of vastly :)

very true... 100 meters would be vast imho. A difference of 5 meters I
would think that is pretty much ok, although the importance of that can
be big when borders cross buildings.

> (I haven't looked at the size of the differences yet)
> 
> I was talking about municipal borders (admin_level=8), postal codes as
> in your example are a wholly different beast, one I wouldn't want to
> tackle right now.

I know it's not level 8, but it doesn't matter what a boundary
represents, I had the Overpass query saved (it's ok to just call me
lazy, not stupid ;-) ! )

All fun aside, in essence: it's really the same, a relation of ways that
have stuff attached.  admin levels are just a label representing concepts.

> But yes, they have a lot of things sticking to them too.

More important: remember that those boundaries usually align on each
other, so when you make a admin level 8 smaller, you -probably- also
need to modify all others as well. e.g.  If you make north border of
Antwerp smaller, you probably need to make Belgium smaller too, AND the
province etc.  probably even from level 1 down to 9 if you want to do
this well.  At the least we will need to verify them to make sure.

GRB data actually has border information if I remember correctly.  some
of their map layers (tiles) show the level 8 boundary (a very fine line
though, almost invisible).

Glenn

> 
> So when is our next hackathon to work on things like this?
> 
> 
> 2016-06-01 16:00 GMT+02:00 Glenn Plas  >:
> 
> Hi,
> 
> I'm not sure they can be vastly improved, it probably depends a lot on
> what boundary.
> 
> In that understanding that there is lot's of stuff attached to those
> boundaries that shouldn't be there.  So when you are working to improve
> boundaries, you'll need to address plenty of those cases, and that will
> slow you down (a lot) and prevent more automated fixes.
> 
> One could also just go in and unglue all stuff that needs to be as a
> preparation and work with clean -closed way- borders, no crap attached.
>  That would open the road for 'program-assisted' changes.
> 
> Little example: http://overpass-turbo.eu/s/gz0
> 
> node 1712080972 : amenity attached to the border
> 
> Greets,
> 
> Glenn
> 
> On 01-06-16 15:46, joost schouppe wrote:
> > RIP Marc.
> >
> > So I understand the geometry of the municipal boundaries could be vastly
> > improved.
> >
> > I'm guessing the easiest workflow would be to load just the geometry of
> > the municipalities and just the OSM municipalities in JOSM, then merge
> > the nodes of the OSM municipalities to the external data. Afterwards,
> > just discard the external geometry. Right?
> >
> > I think I could quite easily identify the largest differences with FME
> > to help set priorities. But I would think this is something where we
> > would just want to copy the official dataset node for node, no?
> >
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> -- 
> Joost @
> Openstreetmap
>  | Twitter
>  | LinkedIn
>  | Meetup
> 
> 
> 
> ___
> 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] municipal boundaries in Belgium

[joost schouppe]

>
> very true... 100 meters would be vast imho. A difference of 5 meters I
> would think that is pretty much ok, although the importance of that can
> be big when borders cross buildings.
>
> Exactly, I think the definition of correct is pretty narrow here.


> More important: remember that those boundaries usually align on each
> other, so when you make a admin level 8 smaller, you -probably- also
> need to modify all others as well. e.g.  If you make north border of
> Antwerp smaller, you probably need to make Belgium smaller too, AND the
> province etc.  probably even from level 1 down to 9 if you want to do
> this well.  At the least we will need to verify them to make sure.
>
> Yes, this is something to keep in mind. As long as you don't go splitting
ways in the wrong place, that shouldn't be a problem though, right? If they
are properly mapped, boundaries like that should reuse the same segments
over and over again, so correct one and you correct all the others. E.g.
http://www.openstreetmap.org/way/87806314



> GRB data actually has border information if I remember correctly.  some
> of their map layers (tiles) show the level 8 boundary (a very fine line
> though, almost invisible).
>
> I think this is the one:
https://download.agiv.be/Producten/Detail?id=1217&title=Voorlopig_referentiebestand_gemeentegrenzen_toestand_29_01_2016
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] municipal boundaries in Belgium

[Sander Deryckere]

Note that the GRB data mentions it's "voorlopig", and often, the data shows
an offset from parcel boundaries. At those places, I would expect the
boundaries to follow parcel boundaries (and I expect parcel boundaries to
be of better quality).

2016-06-01 19:01 GMT+02:00 joost schouppe :

> very true... 100 meters would be vast imho. A difference of 5 meters I
>> would think that is pretty much ok, although the importance of that can
>> be big when borders cross buildings.
>>
>> Exactly, I think the definition of correct is pretty narrow here.
>
>
>> More important: remember that those boundaries usually align on each
>> other, so when you make a admin level 8 smaller, you -probably- also
>> need to modify all others as well. e.g.  If you make north border of
>> Antwerp smaller, you probably need to make Belgium smaller too, AND the
>> province etc.  probably even from level 1 down to 9 if you want to do
>> this well.  At the least we will need to verify them to make sure.
>>
>> Yes, this is something to keep in mind. As long as you don't go splitting
> ways in the wrong place, that shouldn't be a problem though, right? If they
> are properly mapped, boundaries like that should reuse the same segments
> over and over again, so correct one and you correct all the others. E.g.
> http://www.openstreetmap.org/way/87806314
>
>
>
>> GRB data actually has border information if I remember correctly.  some
>> of their map layers (tiles) show the level 8 boundary (a very fine line
>> though, almost invisible).
>>
>> I think this is the one:
> https://download.agiv.be/Producten/Detail?id=1217&title=Voorlopig_referentiebestand_gemeentegrenzen_toestand_29_01_2016
>
>
>
> ___
> 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] municipal boundaries in Belgium

[Ruben Maes]

Wednesday 01 June 2016 19:50:48, Sander Deryckere:
> Note that the GRB data mentions it's "voorlopig", and often, the data shows
> an offset from parcel boundaries. At those places, I would expect the
> boundaries to follow parcel boundaries (and I expect parcel boundaries to
> be of better quality).

What is the authority for this? Who is the boss about where a municipality 
ends? Can it be copied from there? Intuitively I'd think those official borders 
should not be able to be copyrighted.

> (...)

-- 
This message is OpenPGP signed.

signature.asc
Description: This is a digitally signed message part.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be