Re: [OSM-talk-be] Renderen van addr:flats

[Lionel Giard]

The tagging is correct, it is just not supposed to be on area from the wiki
perspective. But indeed I don't see why it is incorrect when a building is
only containing this series of flats and only one entrance ? And if that's
incorrect why are they rendering addr:flats on area and not node ?! ^^'

Le lun. 15 juin 2020 à 13:32, joost schouppe  a
écrit :

> Most of this data comes from the GRB import, I would guess. So it comes
> from CRAB. We use the addr:flats to map the "subaddresses".
> It seems a little weird to not be able to add the subaddresses on the same
> object that has the main address.
> The CRAB import tool mentioned this as an optional tag, that is not so
> useful for OSM:
> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
> I would concur that the quality of the data is not good enough to import
> it.
> Both examples come from endless_autumn, who did a rather quick-and-dirty
> GRB import - a lot of which was reverted.
> The GRB-import-validator Midgard made actually flags the flats tag as
> "consider removing" as well.
> That said, the wiki doesn't say much about the logic of "subaddresses",
> maybe we shouldn't use the addr:flats tag -at all- for subaddresses?
>
>
> Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere  >:
>
>> Hmm,
>>
>> it seems indeed that, according to the wiki, this should not be placed on
>> areas.
>> However, I expect that in all these cases, all flats are accessible
>> behind the same door.
>> So correcting the tag will have the same effect.
>>
>> Op ma 15 jun. 2020 om 09:12 schreef Marc M. :
>>
>>> Hello,
>>>
>>> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
>>> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
>>>
>>> https://www.openstreetmap.org/way/499694374
>>> this look like a mistake :
>>> wiki :  marking range of numbers of flats behind a door,
>>> but the object isn't a door, it's a building
>>>
>>> maybe osm.carto should avoid to render tagging mistake and target
>>> only node and maybe only with entrance or door tag
>>>
>>> Regards,
>>> Marc
>>>
>>> ___
>>> 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 Schouppe
> 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] Telenav Mapping Project

[Lionel Giard]

Great to learn about your project. :-)

I would think that this page of our Belgium convention could be useful to
you : https://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium . It list
our current convention for how to map road signs around here (the
picture on the wiki are generally in dutch, but the same sign exist in
french), notably all the exception signs under the main sign. Some signs
are very uncommon, but just in case, this can help ! :-)

You can always see this wiki page, or if you have a special question, feel
free to ask the community here and/or you can find more ways to contact us
like our "OpenStreetMap BE Matrix channel" to have a quick chat about
something : https://openstreetmap.be/en/contact.html .

Kind Regards,

Le mer. 22 avr. 2020 à 13:09, Adrian Budugan  a
écrit :

> Hi all,
>
> I am Adrian and I am part of the Mapping Team at Telenav. Our team
> started an editing project in Belgium to make OpenStreetMap more
> navigable and accurate in guidance.
>
> We will start editing in Brussels at the end of April, next week. There
> are more details here -
> https://github.com/TelenavMapping/EU_mapping_projects/issues/4.
>
> We will focus on one ways, turn restrictions, road geometry and quality
> assurance.
>
> We we'd love to hear your advice on any local mapping guidelines, besides
> the general OSM mapping ones (http://wiki.openstreetmap.org/wiki/Main_Page
> , http://wiki.openstreetmap.org/wiki/Map_Features).
>
> Also, we appreciate any hints regarding available local or government data
> that we might be able to us or anything else that might come in handy.
>
> If there are any other OSM communication channels for Belgium, please let
> us know.
>
> If you have any questions or comments, please let me/us know.
>
> We are looking forward to hearing from you.
>
>
>
> Thank you!
>
>
>
>
> ___
> 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] Bunkers

[Lionel Giard]

I was just following the wiki on that which says abandoned:building=bunker.
I suppose that they see it as the building is abandoned, so it is the
building that get the prefix. But i also thought like you at a first guess
(i just followed how it was done on the wiki blindly). :-) Thus maybe we
should change/propose a change on the wiki ?

Le mar. 17 mars 2020 à 20:25, Marc Gemis  a écrit :

> are you sure it's not
>
> building=bunker
> abandoned:military=bunker
>
> ?
>
> my reasoning is:  it's still a building, but no longer a military
> installation.
>
> m.
>
> On Tue, Mar 17, 2020 at 5:16 PM Lionel Giard 
> wrote:
> >
> > For abandonned (historic) military bunker, the correct mapping is :
> > - abandonned:building=bunker
> > - military=bunker
> > - bunker_type=* (most of them are pillbox for those defensive belt
> around our big cities)
> > - historic=yes
> > ...
> >
> > So that you get all the information that it is no longer in use ! ^_^
> > Look on the wiki for more detailed tagging:
> https://wiki.openstreetmap.org/wiki/Tag:military%3Dbunker
> >
> > Kind Regards,
> > Lionel
> >
> > Le mar. 17 mars 2020 à 16:51, Marc M.  a
> écrit :
> >>
> >> Hello,
> >>
> >> Le 17.03.20 à 16:26, rodeo .be a écrit :
> >> > I assume they were not visible because the tags were deprecated
> >>
> >> military=bunker isn't deprecated, it's the correct tag for a bunker
> >> still in military use.
> >>
> >> I found at least one currently visible mapped with a node
> >> https://www.openstreetmap.org/node/29049422
> >> another mapped with an area https://www.openstreetmap.org/way/25586752
> >>
> >> Regards,
> >> Marc
> >>
> >> ___
> >> 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
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] BIPT antennas

[Lionel Giard]

ible. Their white color is often even more visible than the support
> itself.
> On other structures like tower, @lionel already mentioned that the
> antennas could be tagged with telecom=antenna
> https://lists.openstreetmap.org/pipermail/tagging/2018-October/040276.html
> .
>
> I can understand that there is no proper way to tag the antennas and the
> group of antennas without specifying the support but it seems a bit
> limiting.
>
> *How to map it?*
>
> @Lionel, you didn't comment on the man_made=antenna tag (Status: in use)
> which was also mentioned in the discussion of 2018.
> There is also this proposal from nov 2018 where the man_made=antenna +
> antenna:application=mobile_phone is suggested (
> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use)
>
> In any case, I don't have enough experiences on tagging and I will follow
> what comes out of this discussion.
>
> Best regards,
>
> Vucodil
>
> March 9, 2020 11:39:20 AM CET Lionel Giard  wrote:
>
> Cool news that they gave the authorization to use it ! And it is always
> great to have some interest on the telecom side. :D I'll give what i know
> and some opinion on the tagging. ^_^
>
> For the tags to use, there was a (rather long) discussion in October 2018
> on Tagging mailing list (
> https://lists.openstreetmap.org/pipermail/tagging/2018-October/thread.html)
> and one output was that the current scheme is probably not good (but
> nothing was decided) ! :p
>
> I had done some manual cleaning on the mast/tower tags 2 years ago i think
> - i looked at mapillary footage especially for mast/tower along motorways
> where it is often easy to spot them or did some survey (and we are not many
> to map these structure so it was quite easy :p ). And the current tagging
> scheme should be (following the wiki and what was clarified in the
> discussion) :
>
> EITHER :
> *- man_made=mast / tower *(really subjective, as we don't have real
> difference but mainly: a tower is generally freestanding and often larger
> diameter/width (think about (often) concrete telecom tower), while a mast
> generally have often some guy wires and/or have a small diameter/width
> (think about metallic mast).
> *- tower:type=communication*
> *- tower:construction=freestanding / lattice / guyed_lattice / guyed_tube*
> (https://wiki.openstreetmap.org/wiki/Key:tower:construction?uselang=en-US)
> *- communication:mobile_phone=yes* (if GSM, which should be the case for
> all thse one).
> - *height=* *(if known)
>
> OR
> - *telecom=antenna* (there is no real other tag for antenna alone, and
> this one is using the telecom=* key as some people want to clarify things).
> *- communication:mobile_phone=yes* (if GSM, which should be the case for
> all thse one).
> - *height=** (if known).
>
>
> => Those two are two different things : the first one is a structure that
> support some antennas (typical GSM mast support multiple antennas), and the
> second is a standalone antenna (on a rooftop for example). *The BIPT only
> give antennas, so we must first determine if it is standalone or on a mast
> or tower.*
>
> There is no approved tagging of multiple antennas on 1 mast or tower (you
> mention the "Radio antennas mapping proposal" but it seems really
> complicated and easy to break with the relations...). Maybe we should just
> create *a custom belgian tag *(similar to how the french are tagging
> their own infrastructure) for the antenna present like :
> - ref:BE:BIPT=21292
> - ref:BE:Proximus=10DLT_01(or ref:BE:PXS if we want an abbreviation ?!
> I did use that in the past on street cabinet but i could change it)
> - ref:BE:Orange=1-32264-W1
> - ref:BE:Telenet=_BW4629P
> Following what is in the technical data and their ID (i took one example
> having the three operators ;-) ). It would keep the different operator
> information like it is done on street_cabinet for exemple. It would also be
> easier to maintain and more difficult to break, because if we put 3 nodes
> next to each other (1 for each antenna), it would be easily broken by
> anyone editing the area (especially in ID editor).
>
> Note that, the operator tag is difficult to assess for the mast or tower
> structure as it could be any one of the multiple antenna operator or even
> someone else (and they don't give this information publicly). So i would
> not use the operator tag except on individual antenna or mast/tower that
> would only have 1 antenna.
>
> We could also use a subtag like antenna=1/2/3/... if we want to give the
> number of antenna on a same support (mast or tower) ?
>
>
> Note that there was some discussion of a "potential" proposal in the
> discussion to change the taggi

Re: [OSM-talk-be] IBPT antennas

[Lionel Giard]

Cool news that they gave the authorization to use it ! And it is always
great to have some interest on the telecom side. :D I'll give what i know
and some opinion on the tagging. ^_^

For the tags to use, there was a (rather long) discussion in October 2018
on Tagging mailing list (
https://lists.openstreetmap.org/pipermail/tagging/2018-October/thread.html)
and one output was that the current scheme is probably not good (but
nothing was decided) ! :p

I had done some manual cleaning on the mast/tower tags 2 years ago i think
- i looked at mapillary footage especially for mast/tower along motorways
where it is often easy to spot them or did some survey (and we are not many
to map these structure so it was quite easy :p ). And the current tagging
scheme should be (following the wiki and what was clarified in the
discussion) :

EITHER :
*- man_made=mast / tower *(really subjective, as we don't have real
difference but mainly: a tower is generally freestanding and often larger
diameter/width (think about (often) concrete telecom tower), while a mast
generally have often some guy wires and/or have a small diameter/width
(think about metallic mast).
*- tower:type=communication*
*- tower:construction=freestanding / lattice / guyed_lattice / guyed_tube* (
https://wiki.openstreetmap.org/wiki/Key:tower:construction?uselang=en-US)
*- communication:mobile_phone=yes* (if GSM, which should be the case for
all thse one).
- *height=* *(if known)

OR
- *telecom=antenna* (there is no real other tag for antenna alone, and this
one is using the telecom=* key as some people want to clarify things).
*- communication:mobile_phone=yes* (if GSM, which should be the case for
all thse one).
- *height=** (if known).


=> Those two are two different things : the first one is a structure that
support some antennas (typical GSM mast support multiple antennas), and the
second is a standalone antenna (on a rooftop for example). *The BIPT only
give antennas, so we must first determine if it is standalone or on a mast
or tower.*

There is no approved tagging of multiple antennas on 1 mast or tower (you
mention the "Radio antennas mapping proposal" but it seems really
complicated and easy to break with the relations...). Maybe we should just
create *a custom belgian tag *(similar to how the french are tagging their
own infrastructure) for the antenna present like :
- ref:BE:BIPT=21292
- ref:BE:Proximus=10DLT_01(or ref:BE:PXS if we want an abbreviation ?!
I did use that in the past on street cabinet but i could change it)
- ref:BE:Orange=1-32264-W1
- ref:BE:Telenet=_BW4629P
Following what is in the technical data and their ID (i took one example
having the three operators ;-) ). It would keep the different operator
information like it is done on street_cabinet for exemple. It would also be
easier to maintain and more difficult to break, because if we put 3 nodes
next to each other (1 for each antenna), it would be easily broken by
anyone editing the area (especially in ID editor).

Note that, the operator tag is difficult to assess for the mast or tower
structure as it could be any one of the multiple antenna operator or even
someone else (and they don't give this information publicly). So i would
not use the operator tag except on individual antenna or mast/tower that
would only have 1 antenna.

We could also use a subtag like antenna=1/2/3/... if we want to give the
number of antenna on a same support (mast or tower) ?


Note that there was some discussion of a "potential" proposal in the
discussion to change the tagging of "telecom mast and tower" into something
looking more like the "power" scheme. Something like that :
- telecom=tower (similar to power=tower grouping everything into one tag)
- structure=guyed_mast, tubes_mast, lattice, tubular/tubes, ...
- tower:type=communication
- communication:mobile_phone=yes

=> This proposal is mainly re-using the common tags used for power scheme :
structure=* instead of tower:construction (François Lacombe - a french
mappers involved a lot in telecom scheme - was proposing that); and
telecom=tower instead of man_made=tower or mast (i was proposing that). It
would simplify the tagging as we would tag everything easily and refine
only in the structure tag. But that was never formally proposed and
approved AFAIK.
I don't know if you want to go into the rabbit holes of trying to adapt a
new tagging scheme for this ahah.
*Anyway we can use the current scheme as it would be easier now. ;-) *

Kind Regards,
Lionel

Le lun. 9 mars 2020 à 00:36, Midgard  a écrit :

> Replying inline to s8evq and Karel:
>
> Quoting s8evq (2020-03-08 20:20:34)
> > What is the point of adding longitude=* and latitude=* to the nodes?
>
> I had overlooked them, but these tags definitely have to be dropped.
>
> > How precise are the locations of the antennas in the BIPT dataset? Do we
> know what the quality of this data is before importing?
>
> The ten or so that I checked were pretty close, within 5 metres. One was
> 

Re: [OSM-talk-be] Tagging proposal for cycling highways (Fietssnelwegen)

[Lionel Giard]

To answer Joost question about relevance in other regions : yes it is
relevant. Wallonia recently started to plan and implement these "cycle
highway" to reach Brussels from multiple different locations (with
protected cycleway along motorway, national road or railway). They want to
connect and continue some of the existing cycle highway in Flanders (like
the F20 near Halle and go further to Tubize...).
That would definitely be a belgian thing, and not only flanders. ^_^

Le mer. 11 déc. 2019 à 10:12, Marc Gemis  a écrit :

> > Tagging scheme
> >
> > I'd actually go for `cycle_network=BE:cycle_highway`, as cycle_network
> normally has a country prefix. Because most (all?) of them are already
> tagged, we could simply update the tagging all at once.  I'll do that next
> week, unless a better proposal or good reason not to is raised.
>
> to be honest I find "network" strange in the context of a single
> cycle_highway. All cycle_highways together form a network, but a
> single one not.
> We do not map the E 19 motorway as car_network:BE:motorway, but we do
> have a relation for all parts of the E 19 in a route-relation (I
> think, OSM website was soo slow yesterday when I tried to access the
> page on E-motorways).
>
> Is this cycle_network value OK with the inventors of that tag ? Wasn't
> it invented recently to distinguish cycle networks from local cycle
> routes ?
>
> In conclusion: I would prefer another way to tag cycle highways
>
> regards
>
> m
>
> ___
> 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] parking_space only for electric vehicle sign combination e9b

[Lionel Giard]

As far as i know, there is no legal access limitation in Belgium to such
space (it is only advisory to not park there if not charging - that's why
we can't do anything when people park on them, except if there is a sign
"do not park or you'll be towed" or other sign that have legal value). So
that's why we generally don't use the access tag for that in our country.
Personnally, I only marked it as "capacity:charging=1" on the
"amenity=parking_space" polygon (like this one
) because i used the same
principle than for parking space "reserved for mother with babies" which
should be tagged as capacity:parent=1 (see the wiki for different values :
https://wiki.openstreetmap.org/wiki/Key:capacity ).

For parking_space=*, i have no opinion (i know that i used it in the past,
because i didn't know of the different capacity:*=* tags).

Le mar. 5 nov. 2019 à 11:39, marc marc  a écrit :

> Hello,
>
> Le 05.11.19 à 11:24, Jakka a écrit :
> > How to indicate a parking_space only for electric vehicle?
>
> access=no + access:conditional=yes @ charging
>
> some use parking_space=charging
> but it's a undocumented value, so maybe no datause
>
> Regards,
> Marc
> ___
> 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] Road side parking ( Was Re: Overdreven gedetailleerde mapping ?)

[Lionel Giard]

Yes technically this is how to map it (at least how it is documented), and
using the mandatory tag "parking:condition" in combination give indication
for people looking at roadside parking (one viewer show these :
https://zlant.github.io/parking-lanes/#15/50.9452/3.1233  with Roeselare as
a somewhat good example as it is well mapped). It is primarily for showing
parking conditon (is it allowed to park ? How much time ?...). But indeed,
the tagging scheme can be improved ! ^_^

Maybe use a combination of the two : parking_space to show the individual
space (and so the capacity) and parking:lane=* + parking:condtion=* to show
the roadside parking and condition of parking. :-)

Kind Regards,

Le mar. 5 nov. 2019 à 10:06, Marc Gemis  a écrit :

> So for those 4 roadside parking spaces: https://osm.org/go/0EpBwBaxP?m=
> I have to split the road a couple of times, add some 3 or 4 parking
> lane tags to indicate it is somehow on both sides, parallel parking in
> marked spots? And I wouldn't be able to add the capacity in the end.
>
> While adding 4 rectangles with tag amenity=parking_space express the same?
>
> For me, there is definitely improvement possible in the tagging schema
> for such situations.
>
> m.
>
>
> On Tue, Nov 5, 2019 at 9:26 AM Lionel Giard 
> wrote:
> >
> > @Marc These parking along street are indeed often not "amenity=parking"
> but probably more related to parking:lane tag (tagged on the highway
> itself). Technically it is suggested to only map these kind of roadside
> parking with the parking:lane tag on the street.
> > But yes, it could be mapped with amenity=parking_space (without
> amenity=parking around it). and we could maybe use the
> "type=site"+"site=parking" relation to group them (as it is suggested for
> complex parking lot already) and allow people to understand that it is
> linked to the road (including the street line in the relation) and that it
> is roadside parking. But it is undocumented to use it that way. ^^
> >
> > Le mar. 5 nov. 2019 à 08:42, Marc Gemis  a écrit :
> >>
> >> Ik map soms ook parkeerplaatsen in een straat met enkel
> >> amenity=parking_space, omdat er geen parking (in de betekenis van
> >> parkeerterrein) is.
> >> Ik vind niet dat elke groep van een paar parkeerplaatsen in een straat
> >> parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
> >> wiki niet moet aangepast worden voor zulke gevallen ?
> >>
> >> m.
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Lionel Giard]

@Marc These parking along street are indeed often not "amenity=parking" but
probably more related to parking:lane tag
 (tagged on the
highway itself). Technically it is suggested to only map these kind of
roadside parking with the parking:lane tag on the street.
But yes, it could be mapped with amenity=parking_space (without
amenity=parking around it). and we could maybe use the
"type=site"+"site=parking" relation to group them (as it is suggested for
complex parking lot already) and allow people to understand that it is
linked to the road (including the street line in the relation) and that it
is roadside parking. But it is undocumented to use it that way. ^^

Le mar. 5 nov. 2019 à 08:42, Marc Gemis  a écrit :

> Ik map soms ook parkeerplaatsen in een straat met enkel
> amenity=parking_space, omdat er geen parking (in de betekenis van
> parkeerterrein) is.
> Ik vind niet dat elke groep van een paar parkeerplaatsen in een straat
> parkings zijn. En het wordt gerenderd, dus kan je je afvragen of de
> wiki niet moet aangepast worden voor zulke gevallen ?
>
> m.
>
> On Mon, Nov 4, 2019 at 4:33 PM Stijn Rombauts via Talk-be
>  wrote:
> >
> > Even terug naar de aanpassingen van Jakka en ook wat aansluitend op
> onderstaande opmerking van Marc. En ook omdat ik in alle stilte al wel wat
> werk van Jakka heb verbeterd (en dan bedoel ik effectief: fouten
> corrigeren):
> > - parkeerplaatsen: Jakka heeft daar de individuele parkeerplaatsen
> gemapt; op zich OK. Maar waarom een aantal wel en de andere niet? En
> vergeet dan niet de amenity=parking (toegevoegd door Anakil): m.a.w. zorg
> er op z'n minst voor dan eerst de grote lijnen in orde zijn, voeg pas
> daarna de details toe (wiki: Mapping parking spaces is an addition, not a
> replacement, to mapping a whole parking lot with amenity=parking.) Jakka
> had trouwens een paar parkeerplaatsen foutief gemapt met amenity= parking.
> Daarna heeft ene philippec binnen de amenity=parking van Anakil nog eens 2
> keer een amenity =parking toegevoegd (zoals deze
> https://www.openstreetmap.org/way/741861188)...? Waarom?
> > - nog parkeerplaatsen: daar (https://www.openstreetmap.org/way/731154048)
> 3 brede parkeerplaatsen getekend terwijl het er 5 smalle zijn...
> > - https://www.openstreetmap.org/way/118797990: lanes=2 --> lanes=1,
> maar turn:lanes=none|merge_to_left vergeten te verwijderen en ook
> cycleway:right=lane vergeten te verwijderen
> > - het gebruik van traffic_calming=island (volgens wiki: A structure
> separating at least two lanes of a highway from each other for a short
> distance.). Dan lijkt dat daar (aan het stukje Zemstbaan dat aansluit op de
> Brusselsesteenweg) heel veel verkeerd gebruikt. Alleen al omdat die
> 'dingen' daar niks met traffic calming te maken hebben, volgens mij.
> > - een aantal fietspaden zijn apart bijgetekend (OK), maar waarom niet
> het stukje langs de Zemstbaan van Zemstsesteenweg naar Brusselsesteenweg?
> De oneway-tag lijkt mij ook een aantal keer te ontbreken. En ook de
> bicycle=use_sidepath op de highways is niet toegevoegd...
> >
> > Dat dingen in osm van jaren oud verbeterd, verfijnd of geüpdatet moeten
> worden, is logisch. Maar dat recente veranderingen nog hopen extra werk
> vragen omdat ze zeer onvolledig of ronduit fout zijn, vind ik behoorlijk
> frustrerend. En met zo'n aanpassingen wordt de databank er ook echt niet
> bruikbaarder op. Soit, 't is ook mijn eigen schuld omdat ik er anderen
> zelden op aanspreek. En Jakka, jij bent zeker de ergste nog niet, verre van.
> >
> > StijnRR
> >
> >
> > Op maandag 4 november 2019 13:08:24 CET schreef Marc Gemis <
> marc.ge...@gmail.com>:
> >
> >
> > > Wel pleit ik er voor een zeker 'gebiedje' dan wel op een gelijke
> maatstaf te behandelen. Als je het doet, zorg dan dat je consequent bent,
> voor de wijk of als het even kan je kleine gemeente.
> >
> > er is ook zoiets als "guerilla mapping"
> > (http://sk53-osm.blogspot.com/2011/01/ive-been-guerilla-mapped.html)
> >
> >
> > m.
> >
> > ___
> > 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
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Neighbourhoods in Ghent mapped as a point

[Lionel Giard]

Yes the node approach is only done when the boundaries are unknown (and so
this is an approximation) but in this case, as we have the boundaries as
open data, we could add them indeed. You can see it in the wiki page too
. Thus, creating a polygon
using the exact boundaries of the open data with the tag
"place=neighbourhood" + "name=*" should be fine. You can just import a
shapefile or similar format in JOSM for example, and tag it correctly.

Le lun. 19 août 2019 à 10:35, Pieter Colpaert  a
écrit :

> Hi all,
>
> Neighbourhoods in Ghent are mapped as a point. See for example
> https://www.openstreetmap.org/node/2274965455
>
> The problem with this is that nominatim will add the neighbourhood to an
> address string, based on the nearest point. An address still in the
> Brugse Poort therefore will get an obvious wrong neighbourhood attached
> to it. See for example
>
> https://nominatim.openstreetmap.org/search.php?q=appelstraat+27%2C+9000+Gent_geojson=1=.
>
> This point is in the Brugse Poort, but it is closest to the point of the
> neighbourhood Malem.
>
> Should we change these point to be polygons instead?
>
> There is also an official Open Data list of “wijken” (which is not
> entirely the same though) on the open data portal of the city of Ghent:
> https://datatank.stad.gent/4/grondgebied/wijken → Should we map these
> bounds in OSM as well? And how?
>
> Kind regards,
>
> Pieter
>
> ___
> 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] folk sports in Belgium

[Lionel Giard]

At the moment the OSM wiki page for sport=pelota only show the description
of the "pelote basque " :
https://wiki.openstreetmap.org/wiki/Tag%3Asport%3Dpelota . Maybe we should
adapt the wiki description to show that this name "sport=pelota" is used
for all regional variation ("basque pelota", "belgian pelota/balle
pelote/kaatsen", ...) ? :-)

Le mar. 6 août 2019 à 13:40, joost schouppe  a
écrit :

> Hi,
>
> After a bit of research, I retagged all "kaatspleinen" / "place de
> pelotte" to sport=pelota. I think this is a decent tag for this. Folk
> sports are hard, because there are local variants, and you have to decide
> if you want to tag with the very specific local way of playing or keep it
> simple and generalize a bit.
>
> I took advantage of the moment to create a little map of the 90 fields in
> Belgium:
>
> https://www.mapcontrib.xyz/t/adc0b8-Folk_sports_in_Belgium#
>
> Which other sports should I add to that map?
>
> --
> Joost Schouppe
> 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] bridge or tunnel?

[Lionel Giard]

artificial' means that ground level matters? The
> ringway around Antwerp (R1) is almost everywhere at level -1, below ground
> level. The cutting is here the artificial structure (using Yves' words this
> time). So where there is a road going overneath, the ringway goes through a
> tunnel...? The same for Joost's example: if you look at the aerial imagery,
> you can see clearly they had to dig out the N28 to get underneath the
> railway and the other roads: thus a tunnel...? And what about the complex
> traffic changers where it is often very hard to see what the original
> ground level was.
> > >
> > > @ Yves: 'Layer' gives a relative position. Something at ground level
> can perfectly have layer=-1 or layer=1. Check the wiki. And further: a
> bridge with layer = 1 doesn't mean it is above ground level; a tunnel with
> layer = -1 doesn't mean it is below ground level.
> > >
> > > @ Tim: What came first is a useless criterion. The E313 was
> constructed before the E314, but it is definitely a bridge of the E313
> above the E314. And the definitions of bridge or a tunnel should be so that
> anyone knows whether to map things as bridge or tunnel without having to
> know in which order roads, railways, etc. were constructed.
> > >
> > > So can someone can come up with a useful definition?
> > >
> > > Can I come up with a definition? I like the length/width ratio, the
> open bridge(like) structure against a confined tunnel(like) structure. And
> the fuzziness of the wiki. But one thing is very clear for me: ground level
> doesn't matter.
> > >
> > > Regards,
> > >
> > > StijnRR
> > >
> > >
> > >
> > > Op dinsdag 28 mei 2019 18:52:50 CEST schreef Marc Gemis <
> marc.ge...@gmail.com>:
> > >
> > >
> > > This is the place:
> > >
> https://www.google.com/maps/@51.2216551,4.0345363,3a,75y,49.39h,77.96t/data=!3m6!1e1!3m4!1sjggCIzrpgLhVFtrn6gYCnQ!2e0!7i13312!8i6656
> > > (sorry no Mapillary images yet).
> > >
> > > Burchtakker (the parallel road) is lowered near the (bicycle) tunnel
> > > under the E34/A11.
> > >
> > > On Tue, May 28, 2019 at 6:36 PM Marc Gemis 
> wrote:
> > > >
> > > > I think there is a tunnel under  the e34 between Antwerpen en
> Zelzate.  There used to be a level crossing which was removed and instead
> they created an underground passage for it.
> > > >
> > > > M
> > > >
> > > > Op di 28 mei 2019 14:46 schreef Lionel Giard  >:
> > > >>
> > > >> @joost schouppe  To me that's indeed a bridge, as you see the same
> structure as on the motorway bridges : a platform supported by pillars
> > > >>
> > > >> A tunnel is generally something that was dig (removing
> earth/material) and consolidated from the inside (most often with concrete)
> like a subway tunnel if you want. It seems pretty rare to dig a big hole,
> make a tunnel and put back the earth on top ! ;-)
> > > >>
> > > >> I can't find example of tunnels that's really like "under a railway
> or motorway", so i would say that probably 99% of the tunnel are below
> ground or mountains/hills (if we exclude the obvious building passage that
> we classify as tunnel in OSM). They are generally longer than wide as
> someone quoted from wikipedia.
> > > >>
> > > >> ___
> > > >> 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
>
> ___
> 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] bridge or tunnel?

[Lionel Giard]

@joost schouppe   To me that's indeed a bridge,
as you see the same structure as on the motorway bridges : a platform
supported by pillars

A tunnel is generally something that was dig (removing earth/material) and
consolidated from the inside (most often with concrete) like a subway
tunnel if you want. It seems pretty rare to dig a big hole, make a tunnel
and put back the earth on top ! ;-)

I can't find example of tunnels that's really like "under a railway or
motorway", so i would say that probably 99% of the tunnel are below ground
or mountains/hills (if we exclude the obvious building passage that we
classify as tunnel in OSM). They are generally longer than wide as someone
quoted from wikipedia.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] bridge or tunnel?

[Lionel Giard]

I agree with the above answer that except #2, all are bridge.

One other method to identify a bridge is to check the structure (either
with a "tablier"/bridge deck which goes from one support to the next, or
with arch like one of the example...). There are typical bridge structure,
while most tunnel are just a concrete passage.

Le mar. 28 mai 2019 à 09:29, Tim Couwelier  a
écrit :

> I'll agree with everyone else on the given selection here.
>
> As for how I try to decide:
> Ideally, you'd have the history of 'what came first'. Whichever level this
> one is at goes as the 'baselevel'.
> Either a new road / railway / .. goes:
> OVER it, making that a bridge
> UNDER it, making it a tunnel
> AT THE ORIGINAL LEVEL, making the existing road/path a bridge or tunnel
> based on how that got adjusted.
>
> That makes this a railway-bridge:
> https://www.google.be/maps/@50.9501557,3.1304248,3a,60y,255.18h,91.97t/data=!3m6!1e1!3m4!1sV8dGdG1hKMYxX3JldKdTSA!2e0!7i13312!8i6656
> But this, just a bit further, and at the same level as the road shown in
> the previous example, a tunnel for cyclists:
> https://www.google.be/maps/@50.9516067,3.1299799,3a,48.9y,281.94h,86.62t/data=!3m6!1e1!3m4!1sPooi08Nvz-feFB6XzaibnQ!2e0!7i13312!8i6656
>
> Hope that makes sense, I personally feel it matches with how people tend
> to label things.
>
>
>
>
>
> Op di 28 mei 2019 om 00:04 schreef Pieter Vander Vennet <
> pieterv...@gmail.com>:
>
>> Cool collection of bridges (except #2). I too think that if its not dug,
>> it's not a tunnel.
>>
>> I have another cool example, not from belgium though:
>> https://www.google.be/maps/@45.5067122,6.6792676,3a,75y,267.08h,77.06t/data=!3m6!1e1!3m4!1stJwtCeCLHlLxMPnVB_ZYdw!2e0!7i13312!8i6656?hl=nl
>>
>> This view is on a bridge (over a small valley) which acts as ski piste
>> (in winter), and continues through a building (which has a ski piste on
>> top).
>>
>> Met vriendelijke groeten,
>> Pieter Vander Vennet
>>
>>
>> Op ma 27 mei 2019 om 22:44 schreef GeDeOn . :
>>
>>> Hi Stijn and all
>>>
>>> In my opinion, a tunnel is something that was dug, in a hill or in
>>> mountain, under a river, ...
>>>
>>> Otherwise I would think of a viaduct.
>>>
>>> In that regard only your case #2 is a tunnel.
>>>
>>> Just my 2 cents...
>>>
>>> Pierre
>>>
>>>
>>>
>>> Envoyé depuis mon smartphone Samsung Galaxy.
>>>
>>>  Message d'origine 
>>> De : Stijn Rombauts via Talk-be 
>>> Date : 27/05/19 20:57 (GMT+01:00)
>>> À : OpenStreetMap Belgium 
>>> Cc : Stijn Rombauts 
>>> Objet : [OSM-talk-be] bridge or tunnel?
>>>
>>> Hi,
>>>
>>> 1. This is a bridge: no doubt.
>>>
>>> https://www.google.be/maps/@50.9628551,5.0810297,3a,75y,328.21h,89.12t/data=!3m6!1e1!3m4!1sXz43z9vWyUiOpCVTschIUQ!2e0!7i13312!8i6656?hl=nl
>>>
>>> 2. This is a tunnel: sure enough.
>>>
>>> https://www.google.be/maps/@50.6138142,5.5973887,3a,75y,97.64h,84.03t/data=!3m6!1e1!3m4!1sRvKwojNbhvMdSBWG3zViLw!2e0!7i13312!8i6656?hl=nl
>>>
>>> 3. This looks like a tunnel, no? Or is the fact that the railway is on
>>> an embankment enough reason to make it a bridge?
>>>
>>> https://www.google.be/maps/@50.5508531,4.7216376,3a,89.9y,51.8h,87.45t/data=!3m6!1e1!3m4!1s4GoklQWnN5bW6ugdo1grmg!2e0!7i13312!8i6656?hl=nl
>>>
>>> 4. This one looks more like a bridge:
>>>
>>> https://www.google.be/maps/@50.5923923,4.6668939,3a,75y,57.67h,80.29t/data=!3m6!1e1!3m4!1s4y-C9gvI9ZsUk9jcNQX4eA!2e0!7i13312!8i6656?hl=nl
>>>
>>> 5. And this? Brunnel or tidge?
>>>
>>> https://www.google.be/maps/@50.5214486,4.8868137,3a,75y,27.85h,81t/data=!3m6!1e1!3m4!1sx0n9EuFTEx27S4sCQ--GPg!2e0!7i13312!8i6656?hl=nl
>>>
>>> 6. And if it gets shorter?
>>>
>>> https://www.google.be/maps/@50.5317414,4.9485687,3a,75y,39.18h,91.35t/data=!3m6!1e1!3m4!1sdTd6puiPIvGKsLBzeCzB6Q!2e0!7i13312!8i6656?hl=nl
>>>
>>> 7. And this?
>>>
>>> https://www.google.be/maps/@50.8660892,4.3648486,3a,75y,333.02h,85.73t/data=!3m6!1e1!3m4!1swvUHgLYhl8R5IXGVJ2QWiQ!2e0!7i13312!8i6656?hl=nl
>>>
>>> 8. A bit more complicated: not only a railway, but also the platforms on
>>> a bridge? Or above a tunnel?
>>>
>>> https://www.google.be/maps/@50.8101922,4.3991964,3a,75y,63.96h,87.57t/data=!3m6!1e1!3m4!1s2ioHz72P7Ju0aTcMLalGKg!2e0!7i13312!8i6656?hl=nl
>>>
>>> 9. And if you turn around:
>>>
>>> https://www.google.be/maps/@50.8101922,4.3991964,3a,75y,258.54h,101.02t/data=!3m6!1e1!3m4!1s2ioHz72P7Ju0aTcMLalGKg!2e0!7i13312!8i6656?hl=nl
>>>
>>> I am curious about your opinion...
>>> But of course, what those things are, is not really the question. How
>>> should they be mapped? That's the question.
>>>
>>> Regards,
>>>
>>> StijnRR
>>>
>>> ___
>>> 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
> 

Re: [OSM-talk-be] Mapping station Leuven

[Lionel Giard]

Hi,
Ik zal antwoorden in het Engels omdat ik niet veel Nederlands spreek.
--

First, i would recommend you to check the OSM wiki on railway station :
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstation . It explains how
we map them around the world (with a good schema representing it).
It is always good to look at our OSM wiki to understand "how" and "why"
something is mapped that way !

You'll see that the platform ("perron") number or letter is tagged on the
tag "ref=" and not on the name (as it is how we do it). So, it is not
correct to put this information on the "name" tag (using the common method
of mapping the stations). We are always open to argument if you think that
this method of mapping is not optimal (okay, some people might be more open
than others, but you can always discuss the tagging method ! ^^).

Also, the landuse area is something useful for many data users so i won't
touch it (it represent the area used for railway stuff). It is similar to
the landuse=residential polygon that cover large part of our
cities/villages, ...
It is absolutely *cor**rect* and should not be removed ! ;-)

One thing that we should not forget when we map is that a lot of different
people use this data, and they all have different interest (you may not
find it interesting or useful, but other might find it of extreme
importance).

Regards,
Lionel





Le dim. 19 mai 2019 à 17:26, Karel Adams  a écrit :

> Het mappen van stations en spoorwegen is helemaal niet mijn ding, maar
> ik heb er me nu toch aan gewaagd.
>
> * in het station van Leuven heb ik aan de diverse perrons een "name="
> toegevoegd (C/B , A/1, 2/3 ) , is dat een correcte manier van werken?
> Die perrons hadden al zo'n verwijzingen in een "ref=" tag maar die lijkt
> me eigenlijk niet zo zinvol..?
>
> * ik ben in de war met way 89449057, die beslaat een ruim oppervlak aan
> de zuidkant van het station, en heeft als enige tag "landuse=railway";
> aan de noordkant is er ook zo eentje, way 79208741. Hebben die enig nut,
> of toegevoegde waarde? Ik voel een sterke neiging ze te verwijderen (als
> IT-infrastructurist zie ik niet graag nutteloos gebruik van de
> beschikbare middelen :) ) maar omdat ik op onvertrouwd domein ben vraag
> ik eerst maar eens rond :)
>
> Karel
>
>
> ___
> 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] Importing polygons of administrative boundaries for Belgium into OSM

[Lionel Giard]

I know that it's not always possible but in some cases, you can find the
boundaries via the boundary stones (when they exists like in
buildings/chapels). But they are generally well hidden - it often need
local knowledge like from local notary of the village or local
historican... And if you have contact with the municipality, you can get
the information directly when they made a small change in the cadastre to
reflect reality (like when they correct huge mistakes in the cadastre from
more than a century ago).

But i'm pretty sure that cadastre is not yet up to good accuracy (compare
to reality) at the moment. They are improving their data but, as far as i
know, it is not yet corrected everywhere.
For example, in a lot of rural areas, the cadastre was made from the center
of the agglomeration (i.e. the best accuracy is found near the church or
the center of the village) and if you go more and more away of this center,
you'll find big errors or incertitude in the data (like the cadastre
parcels can be few dozen meters off reality).  Relative to other cadastre
parcels, the cadastre data is correct but not if you put our OSM data on
top, it will not match for the comparable data like the location of
streets, ...
That's why i say that i will not *YET *import blindly the cadastre
administrative data, as it *can *be "imprecise" relative to the reality at
the moment.

Le mar. 7 mai 2019 à 10:42, K W via Talk-be  a
écrit :

> Good morning,
> thanks a lot for your reply. It is difficult to see for me how you could
> see "by field survey" where administrative boundaries run. This is
> impossible, as they are not a physical feature. Therefore, the only valid
> reference are the official data. I agree that OSM is quite good, but there
> are definitely instances where the borders deviate by "a few metres" or
> more – which, for certain purposes, makes a big difference. Indeed, so far
> I have corrected mistakes by hand, based on the cadastre. As the only valid
> data one could imagine when it comes to administrative boundaries are the
> official ones (be it from the cadastre or from ING) it would still, in my
> opinion, be better to import those into OSM rather than correcting manually
> here and there.
>
> On Tuesday, May 7, 2019, 9:58:05 AM GMT+2, Lionel Giard <
> lionel.gi...@gmail.com> wrote:
>
>
> Hello,
>
> To me this dataset is not necessarily better than what we have in OSM (as
> we corrected some border by field survey  where this dataset is wrong).
> I would never "replace" blindly all existing geometry by this one. I think
> we can say that we are more or less correct (i never saw errors of more
> than a few meters) - and i find it better to improve the current boundaries
> by hand : checking the official sources, the reality on the ground, ... For
> example, i had a part of a street that i surveyed recently where the
> addresses changed of municipality (to have the whole street in the same
> municipality and not cut it before the last three houses). We are correct
> in OSM, but not yet in the official data (as they don't update often
> enough).
>
> Technically, it is not the official source for administrative boundaries
> in Belgium, as the official source is the Cadastre - which is also open -
> but it is not yet accurate enough (even if they are improving it a lot
> recently).
>
> Le mar. 7 mai 2019 à 09:21, K W via Talk-be  a
> écrit :
>
> EN: Good morning, from time to time I make adjustments in OSM where the
> boundaries between municipalities in OSM are not exactly following the
> official data. However, this is a tedious process, and it would be nice, of
> course, to have the exact data for all Belgium municipalities (and former
> municipalities – "deelgemeenten"/"sections") in one go.
> Now, I have seen that it is possible to download the official border
> polygons from the site of the National Geographic Institute for free: IGN
> - produits - Données numériques <http://www.ngi.be/FR/FR1-5-2.shtm> . The
> only problem is that I have no clue whatsoever how this could be done
> technically, i.e. to replace the existing municipal boundaries in OSM by
> the correct polygons from IGN. Could anybody help with this?
>
> IGN - produits - Données numériques
>
> <http://www.ngi.be/FR/FR1-5-2.shtm>
>
>
> NL: Goedemorgen, af en toe maak ik correcties in OSM waar de grenzen
> tussen gemeenten in OSM niet precies de officiële gegevens volgen. Maar dat
> is een moeilijke procedure en het zou natuurlijk leuk zijn om de precieze
> gegevens voor alle Belgische gemeenten (en vroegere gemeenten –
> "deelgemeenten") in een keer te hebben.
> Nu heb ik gezien dat het mogelijk is om de officiële grenspolygonen van de
> webpagina van het Natio

Re: [OSM-talk-be] Importing polygons of administrative boundaries for Belgium into OSM

[Lionel Giard]

Hello,

To me this dataset is not necessarily better than what we have in OSM (as
we corrected some border by field survey  where this dataset is wrong).
I would never "replace" blindly all existing geometry by this one. I think
we can say that we are more or less correct (i never saw errors of more
than a few meters) - and i find it better to improve the current boundaries
by hand : checking the official sources, the reality on the ground, ... For
example, i had a part of a street that i surveyed recently where the
addresses changed of municipality (to have the whole street in the same
municipality and not cut it before the last three houses). We are correct
in OSM, but not yet in the official data (as they don't update often
enough).

Technically, it is not the official source for administrative boundaries in
Belgium, as the official source is the Cadastre - which is also open - but
it is not yet accurate enough (even if they are improving it a lot
recently).

Le mar. 7 mai 2019 à 09:21, K W via Talk-be  a
écrit :

> EN: Good morning, from time to time I make adjustments in OSM where the
> boundaries between municipalities in OSM are not exactly following the
> official data. However, this is a tedious process, and it would be nice, of
> course, to have the exact data for all Belgium municipalities (and former
> municipalities – "deelgemeenten"/"sections") in one go.
> Now, I have seen that it is possible to download the official border
> polygons from the site of the National Geographic Institute for free: IGN
> - produits - Données numériques  . The
> only problem is that I have no clue whatsoever how this could be done
> technically, i.e. to replace the existing municipal boundaries in OSM by
> the correct polygons from IGN. Could anybody help with this?
>
> IGN - produits - Données numériques
>
> 
>
>
> NL: Goedemorgen, af en toe maak ik correcties in OSM waar de grenzen
> tussen gemeenten in OSM niet precies de officiële gegevens volgen. Maar dat
> is een moeilijke procedure en het zou natuurlijk leuk zijn om de precieze
> gegevens voor alle Belgische gemeenten (en vroegere gemeenten –
> "deelgemeenten") in een keer te hebben.
> Nu heb ik gezien dat het mogelijk is om de officiële grenspolygonen van de
> webpagina van het Nationaal Geografisch Instituut gratis te downloaden:
> http://www.ngi.be/FR/FR1-5-2.shtm. Het enige probleem is dat ik geen idee
> heb hoe je dat technisch moet doen, dus hoe de huidige gemeentegrenzen op
> OSM te vervangen door de correcte polygonen van het NGI. Zou iemand kunnen
> helpen?
>
> FR: Bonjour, du temps en temps je fais des corrections dans OSM où les
> frontières entre les communes dans OSM ne suivent pas les données
> officielles. Mais cela est un processus pénible et il serait agréable, bien
> sûr, avoir les données exactes pour toutes les communes belges (et communes
> anciennes – "sections") d’un seul coup.
> Or, j’ai vu qu’il est possible télécharger gratuitement les polygons
> officiels des frontières du site de l’Institut National Géographique:
> http://www.ngi.be/FR/FR1-5-2.shtm. Le seul problème est que je n’ai
> aucune idée comment faire cela techniquement, c’est à dire comment
> remplacer les frontières communales existantes dans OSM par les polygons
> corrects de l’IGN. Est-ce que quelqu’un pourrait aider ?
>
> DE: Guten Morgen, ab und zu bringe ich Korrekturen in OSM an, wo die
> Grenzen zwischen den Gemeinden in OSM nicht genau den offiziellen Daten
> folgen. Aber das ist natürlich ein mühsamer Prozess, und es wäre natürlich
> schön, die genauen Daten für alle belgischen Gemeinden (und früheren
> Gemeinden – "Teilgemeinden") auf einmal zu haben.
> Jetzt habe ich gesehen, dass es möglich ist die offiziellen Grenzpolygone
> auf der Webseite des Nationalen Geographischen Instituts gratis
> herunterzuladen: http://www.ngi.be/FR/FR1-5-2.shtm. Das einzige Problem
> ist, dass ich keine Ahnung habe, wie man das technisch machen müßte, mit
> anderen Worten wie man die Gemeindegrenzen, die in OSM derzeit existieren,
> durch die korrekten Polygone des ING ersetzen könnte. Kann mir da jemand
> helfen?
>
> Many thanks/hartelijk dank/merci beaucoup/vielen Dank!
> ___
> 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] Looking how tagging "ijskelder"

[Lionel Giard]

Not being doesn't mean it is badly tagged, it just mean that the map on the
website (which is only one map out of many) doesn't show this kind of
details. OpenStreetMap is still a database first, and not a map. Try to not
"map for the renderer" but rather stay with correct tagging. And if you
want to show some data that are not rendered, you can always use custom
maps like umap.

Or one way to see it on maps and still be correct for tagging is : if this
is an historic "ice cellar" you can always put historic=yes (or ruins)
and/or tourism=attraction if relevant and interesting for tourism. The tag
"historic=*" allow it to be visible on the http://gk.historic.place/ map
(only historical elements) and tourism=attraction shows up on the osm map
itself).

Le jeu. 21 mars 2019 à 17:07, Hubert Christiaen <
hubert.christi...@telenet.be> a écrit :

> Op 21/03/19 om 13:08 schreef Marc Gemis:
> > There is a proposal for cellar entries that mentions icehouse:
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:man_made%3Dcellar_entrance
>
> I tried that for a ice cellar in Heverlee, but it was not rendered on
> the map.
>
> Sincerely,
> Hubert
>
> --
> Hubert Christiaen
> Bloesemlaan  17
> 3360 Korbeek-Lo
> Belgium
>
>
> ___
> 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] landuse & highways

[Lionel Giard]

For what i understand, the landuse=grass is mostly a "landcover=grass" tag
which was never properly named (and thus it is used like that). The
surface=grass alone doesn't mean much in OSM as the surface tag is (i
think) only a secondary tag (adding information to other object like
highway=* ).

For the original question, it seems indeed to be less accepted to connect
the landuse to the highway! And i find that it is so much easier to edit
when it is not connected to the highway (or to the landuse on the other
side) as it can just be directly moved without splitting first. If you want
to map the area of an highway there is the proposal of tag "area:highway=*"
that can be used but is not rendered at the moment (see here :
https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area). But it
could in the future if the usage become more prevalent.

Le mar. 19 mars 2019 à 19:55, Karel Adams  a écrit :

> For what it is worth (and I do not think much of that, myself!): the
> landuse tag is one of the most confusing and most misused.
>
> In my self-assigned job of mapping aerodromes, and improving on them, I
> often see tags like
>
> landuse=grass
>
> and that seems incorrect to me, it ought to be surface=grass rather
>
> Correct usage of landuse includes (in my very personal appreciation!)
> landuse=industrial, landuse=military, landuse=commercial,
> landuse=recreational and more such. What that means to the mapping of
> highways is beyond my comprehension; and, to be frank, beyond my interest.
> I only wanted to give my opinion on the general usage of the landuse= tag.
> Perhaps the best application of the landuse tag to highways - but also to
> railways, canals, aerodromes, , would be landuse=infrastructure or
> landuse=public_infrastructure
>
> NB wasn't there a dedicated mailing list about tagging?
>
> For what it is worth,
>
>
> On 19/03/2019 18:33, Stijn Rombauts via Talk-be wrote:
>
> Hi,
>
> What are the opinions these days about landuse mapping: connect landuses
> to highways or let space between landuse polygons and adjacent highways?
> Is there a consensus or can everyone do whatever he/she likes?
> My opinion: I *hate* landuse connected to highways.
>
> Regards,
>
> StijnRR
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://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

[OSM-talk-be] Réunion OSM à Louvain-la-Neuve / OSM meeting in Louvain-la-Neuve - 11/02/2019

[Lionel Giard]

*Excuses voor de nederlandstalige mensen, omdat de bijeenkomst plaats
vindt in Louvain-La-Neuve, heb ik geen vertaling van dit bericht in
het Nederlands, maar je bent natuurlijk van harte welkom! We spreken
hier Nederlands, Frans en Engels !*

*### Français ###*

Bonjour à tous,

Nous vous invitons au prochain meetup en Brabant Wallon à *LLN
(Louvain-la-Neuve) *ce *lundi 11 février* à la *Crêperie Bretonne - La
Mère Filioux* (délicieuses crêpes et bière !).
Nous sommes de plus en plus nombreux dans les environs et cela sera
une occasion de se rencontrer !

Nous espérons vous y voir nombreux !

Toutes les informations se trouvent ici
:https://www.meetup.com/fr-FR/OpenStreetMap-Belgium/events/258161886/

Bonne journée,

Lionel Giard

*### English ###*

Hello,

We've just created the meetup for the next meetup in *LLN
(Louvain-la-Neuve)* on *Monday the 11th of February* at la *Crêperie
Bretonne - La Mère Fillioux* (remember -> delicious pancake and beer
!), I hope it will attract more people ! ;-)

Everybody is more than welcome to come!

All information can be found here :
https://www.meetup.com/fr-FR/OpenStreetMap-Belgium/events/258161886/

Looking forward seeing you there!

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

[OSM-talk-be] Tourism : How to tag a regional / local rating ? / Tourisme : Comment tagger les labels touristiques ?

[Lionel Giard]

[Pour les francophones, j'ai traduits à peu près en-dessous :-) ]

Hi everyone,

I asked on the community riot channel how to tag a regional tourism rating
as i'm mapping tourism sites in Wallonia. We were not sure, so i bring the
question to the mailing list.

To give everyone the details : there is apparently three ratings in use in
Wallonia [1], the '*étoiles*' ('stars') used for hotel/camping/...,  the "
*épis*" used for guest houses (and things like Bed & Breakfast) and finally
the more recent "*soleil*" (literally 'sun') given to tourism attraction
(there is a protected designation for the words "attraction touristique" in
Wallonia). There are probably other local rating that i'm not aware of
(especially in other regions* => Is there a similar designation for
Flanders or Brussels ?*). These are verifiable both on the official list of
the CGT (Commissariat général du Tourisme) or on the ground in most case.

As i mapped some guest house, i added a custom tag *epis=** similar to the
*stars=** tag used widely around the world for hotel... But i was asked if
it would not be better to use a more general tagging scheme for these
"local rating" ? Maybe something like *official_rating:epis=* *or other ?
But then it would be different than the widely used stars=* tags. What is
your thinking and proposition about it ?

Regards,
Lionel Giard (alias Anakil in OSM)

[1] Documentation in french :
- étoiles (stars) for hotel : https://www.tourismewallonie.be/lhotellerie
- étoiles (stars) for camping (different criterias than hotel) :
https://www.tourismewallonie.be/camping
- épis :
http://pro.ftlb.be/index.php/votre-secteur/tourisme-de-terroir/229-epis
- soleil :
https://www.tourismewallonie.be/des-soleils-pour-attractions-touristiques-wallonnes

__

Bonjour à tous,

J'ai demandé à la communauté belge sur le chat Riot quels attributs
utilisés pour un label touristique régional en cartographiant en Wallonie.
Nous n'étions pas sûr, donc j'amène la question dans la "mailing list".

Pour donner un contexte à cela, il y a apparemment trois labels
touristiques en Wallonie [1] : les "*étoiles*" pour les hôtels/camping/...,
les "*épis*" pour les chambres d'hôtes/gîtes/Bed & Breakfast, et les "
*soleils*" pour les attractions touristiques (c'est apparemment une
appellation protégée). Il y en a sûrement d'autres que je ne connais pas
ici (ou dans d'autres régions *=> Par ailleurs, connaîtriez-vous des labels
similaires en Flandres ou à Bruxelles ?*). Ces labels sont vérifiables à la
fois dans les listes de la CGT (Commissariat Général du Tourisme) ou sur le
terrain en général.

Et comme je cartographais des chambres d'hôtes, j'ai ajouté l'attribut
*epis=** (que j'ai créé pour l'occasion), c'est-à-dire un attribut
similaire à *stars=** (pour les étoiles d'hôtels...). J'ai réçu la question
de savoir s'il ne serait pas mieux d'utiliser des attributs plus généraux
car on est sûrement pas la seule région à utiliser des labels touristiques.
Quelque chose comme *official_rating:epis=* *par exemple? Le problème étant
que le tag  *stars=**   est déjà très utilisé dans le monde et que donc, on
aurait un schéma de tagging différent pour certains tags mais pas tous.
Qu'en pensez-vous ?

Bien à vous,
Lionel Giard (alias Anakil dans OSM)

[1] Documentation en français :
- étoiles pour les hotels : https://www.tourismewallonie.be/lhotellerie
- étoiles pour les campings : (different criterias than hotel) :
https://www.tourismewallonie.be/camping
- épis :
http://pro.ftlb.be/index.php/votre-secteur/tourisme-de-terroir/229-epis
- soleil :
https://www.tourismewallonie.be/des-soleils-pour-attractions-touristiques-wallonnes
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Tour de contrôle

[Lionel Giard]

Juste pour donner plus d'informations sur les tags utilisés pour le moment.
Le tag le plus utilisé pour cela est
"man_made=tower" + "service=aircraft_control" (voir :
https://wiki.openstreetmap.org/wiki/Tag:service%3Daircraft_control ). Ce
tag est utilisé 369 fois.
Il vient d'une vieille proposition (dont je n'ai pas retrouvé de lien) et
semble utilisé quasiment partout.

Je n'ai pas d'avis pour l'un ou l'autre personnellement mais peut-être
qu'il serait bon de mener la discussion sur la mailing list générale
"Tagging"  car cela impacte tout le monde je crois.

Bien à vous,

Le jeu. 22 nov. 2018 à 09:40, Florian LAINEZ  a écrit :

> Hello,
> En m'intéressant aux tours de contrôle des aéroports, je me rend compte
> qu'il n'y pas vraiment de consensus sur le tag à utiliser.
> Le wiki 
> n'est pas très explicite sur le sujet et mes recherches sur le sujet n'ont
> pas abouti à grand chose.
>
> D'après moi il faudrait utiliser
>
> *made_man=tower*
> *tower:type=aircraft_control*
> Cette combinaison n'est utilisée que 3 fois en france
>  mais ça me parait la bonne.
>
> Qu'en pensez-vous ?
>
> Si on se met d'accord on peut facilement trouver et tagger toutes les
> tours de contrôle de France. Dans un premier temps j'ai envie d'ajouter ces
> tags aux objets nommés "Tour de contrôle"
>  (en vérifiant à la mano chaque objet)
> puis de chercher une tour pour chaque aéroport, tout simplement.
> Cheers
>
> --
>
> *Florian Lainez*
>
> 0033 6 31 02 71 08
> @overflorian 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] osm - arlon - training course / evangelism

[Lionel Giard]

Hi Pierre,

I saw a influx of new mappers (via the welcome page) around Arlon following
your formation i suppose, and i detected a few mistakes that were common :
- uploading polygons without tags (i suppose the JOSM validator was either
not activated or just ignored on purpose ?!);
- a few miss-click with node without tags or node/lines moved from their
original position (again most  of them should be detected by the validator).

I don't know if you had time to do what you planned, but i would recommend
insisting on the validator part !
Globally, the geometries are correct, the main problem is really just to
not forget tagging them. ;-)

I also saw that some of them added housenumber without any other tag on the
buildings, don't forget to tell them that an address is at least "number,
street (and postal_code if it doesn't exist in a polygon)". ^^

Regards,

Le lun. 29 oct. 2018 à 20:10, Pierre Parmentier 
a écrit :

> As suggested by Joost Schouppe, I give you here more info about
>
> On Monday 23 October 2018, I delivered my first hours of evangelism on
> OpenStreetMap.
>
> Regular visitors to the Espace public numérique (EPN) of Arlon as well as
> people particularly interested in the subject, such as members of the
> Association Les Sentiers de Grande Randonnée, were present.
>
> For three hours in the morning and again three hours in the afternoon, I
> talked and showed screens about the 'use' of OpenStreetMap in everyday
> life. The means of 'contributing' and participating in the database will be
> explained on 6 and 27 November.
>
> Let me say that it was difficult for me to speak of all the elements that
> I had promised myself to explain. Time is short with OpenStreetMap! The
> audience had a very varied computer experience. For some people, the use of
> the mouse was still unclear in all situations. But many interesting and
> constructive questions have been raised. And at the end of each session, we
> did not reach half of the program! But all visitors received a brief
> program (paper and PDF) as well as a clear list of all the websites I
> planned to visit.
>
> Very, very beautiful experience! More details after the next two steps.
>
> All with the support of some contributors of the Pays d'Arlon
>  and the manager
> of the EPN.
>
> Regards.
>
> Pierre Parmentier
> ___
> 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] cadastral plan now open data

[Lionel Giard]

I'm not supporting the addition of this WMS neither, as it is more
imprecise than others sources for most of the data. So the question about
the license is not really important in that case. The regional sources for
buildings, parcels, streets,... are almost always with a better precision.

One important thing that the cadastre give, is the administrative boundary
as it is the authorithy on this subject (to keep the cohesion with parcels
and administrative boundaries) as explained here
https://data.gov.be/fr/dataset/b47f2ffd-ebc9-413c-903f-d83af520fcdb (you
can choose the language at the top left of the page) :
*"The General Administration of Patrimonial Documentation of the FPS
Finances was designated by the other institutes as being the authentic
source for this database and manages it as such"* -> this is the layer
"B_CaPa" in the downloadable data. So this would be the useful part of the
cadastre, But i don't think we need the wms for that, if we want to improve
the administrative boundary, we can just download the layer and use it as a
base, to re-position the boundaries.

Le ven. 21 sept. 2018 à 12:49, joost schouppe  a
écrit :

> Hi,
>
> André asked to include the WMS of this service by default in the JOSM
> repository. A long conversation ensued. Some of the confusion is caused by
> the fact that the WMS probably contains outdated license info. I have now
> asked the FOD Finances for a second time to clarify this. The ticket was
> closed, which is probably a good thing, as it is probably not a good idea
> to show this data by default in JOSM anyway!
>
> But even for the license of the downloadable files the JOSM team seemed a
> bit worried: https://josm.openstreetmap.de/ticket/16693#comment:7
> When I read the license, I felt attribution requierement in the license
> was defined loosely enough that mentioning it under Contributors would be
> enough. It would be nice to hear from other people how they interpret this
> license.
>
> Op vr 24 aug. 2018 om 13:58 schreef joost schouppe <
> joost.schou...@gmail.com>:
>
>> Hi,
>>
>> The cadastral plan is now open data for the entire country!
>>
>> That's pretty big because:
>> - for Wallonia, it's the first open vector data with parcels, buildings,
>> roads and road names.
>> - contains "underground buildings" which were not available anywhere
>> AFAIK.
>> - there's a dataset with roads that have some kind of
>> "erfdienstbaarheid"/"servitude". This might be of use for certain dubious
>> paths
>>
>> But of course, please note:
>> - there is way more data where this came from - the attributes of the
>> parcel are not included (like building levels, number of units, landuse)
>> - Belgian cadastre data has a bad reputation in general so do not trust
>> everything you see. The building geometry seems to be quite poor,
>> especially when it comes to exact positioning, not so much the shape itself.
>> - do not trust road name data (it doesn't follow the CRAB name, so not
>> official in Flanders). Names are often abbreviated
>> - the roads do not form a network, there are duplicate geometries and
>> some geometries are outdated by half a century
>> - there is pretty good metadata included. However, you might find data
>> that does not follow the explained model
>>
>> The license file is included in any download. It seems to be compatible
>> with OSM, but it would be nice if more people give it a good read. The
>> first one to use it for mapping, does need to add it to
>> https://wiki.openstreetmap.org/wiki/Contributors
>>
>> The data is in shapefile format (b!), but Philippe Duchesne has made
>> a download site where you can get it in geopackage format. There is also a
>> "view" link. To actually see the data there, find the big switches to
>> activate the layers you want to see. The bigger ones take a while to load!
>>
>> More details:
>> * Official website:
>>
>> https://financien.belgium.be/nl/particulieren/woning/kadaster/kadastraal-plan
>>
>> https://finances.belgium.be/fr/particuliers/habitation/revenu_cadastral/plan-cadastral
>>
>> * Metadata:
>>
>> https://financien.belgium.be/sites/default/files/20180626_Dataspecificaties.pdf
>>
>> https://finances.belgium.be/sites/default/files/20180626_Specificationsdata.pdf
>>
>> * Repackaged into an open data format:
>> http://data.highlatitud.es/cadaster-belgium/
>>
>> We think this data will only be usable for validation efforts. If you
>> think an import could be useful for some of the data in some places, do not
>> forget to follow the Import Guidelines or risk having your work reverted.
>>
>> Happy mapping,
>> --
>> Joost Schouppe
>> OpenStreetMap  |
>> Twitter  | LinkedIn
>>  | Meetup
>> 
>>
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter 

Re: [OSM-talk-be] Note tells OSM fails

[Lionel Giard]

The official french name is "Kraainem" too, while Crainhem is an alternate
spelling for french (but i had never seen it before). Maybe we should
change the tag and put it like that "name:fr=Kraainem" and "alt_name:fr=
Crainhem" ?

Le mar. 4 sept. 2018 à 20:43, Marc Gemis  a écrit :

> I replied with the same names as person used in the original note.
> Kraainem is named Kraainem in the name and name:nl fields.
>
> It is possible that Nominatim returns the name:fr field in case you
> have your browser configured to prefer French above Dutch.
>
> m.
> On Tue, Sep 4, 2018 at 7:21 PM Karel Adams  wrote:
> >
> > In the margin and without wishing to enter politics, allow me to insist
> > we should name the village by its primary and original name "Kraainem".
> >
> >
> > On 04/09/18 09:39, Marc Gemis wrote:
> > > Here is the answer I gave on the note:
> > >
> > > As you can see on the map, the boundary between Woluwe-Saint-Pierre
> > > and Crainhem runs slighty left of the Rue Longue.
> > >
> > > Since the current implementation of Nominatim (the software that looks
> > > up the addresses), always looks at the street and never at the POIs,
> > > there is no way to solve this with data.
> > >
> > > AFAIK, they are working on a solution for this, but there is no
> > > timeframe for a solution
> > >
> > > m.
> > > On Tue, Sep 4, 2018 at 9:38 AM Jakka  wrote:
> > >> Hi,
> > >>
> > >> Who can answer and close this note.
> > >> Building is located in Woluwe-Saint-Pierre but access highway is in
> > >> Crainhem I think...
> > >> https://www.openstreetmap.org/note/1477650#map=19/50.84217/4.46717
> > >> https://nominatim.openstreetmap.org/details.php?place_id=84536059
> > >>
> > >>
> > >> ___
> > >> 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
>
> ___
> 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] landuse mapping

[Lionel Giard]

I would also be interested, virtually or even real meeting. ;-)

Lionel


2017-11-08 17:10 GMT+01:00 joost schouppe :

> Hi,
>
> We would have loved to have a landuse-mapping debate during Foss4G, it
> didn't really happen though. There were two very cool presentations about
> landuse mapping though, by Julien Minet and Julien Radoux.
>
> You can see Julien's presentation here [1]. It does a nice job of
> summarizing the state of the landuse map, and shows some of the current
> mapping dilemmas.
>
> Julien Radoux explained how OSM is useful - and sometimes fails - for his
> project to map the landcover in Wallonia for the Lifewatch project [2].
> This data is available for download and could possibly be interesting for
> us - not for a simple import, but at least as food for a mapping challenge
> to map Wallonia landuse in detail.
>
> The agenda of the meeting would be:
> - work on a Belgian proposal to deal with current dilemmas, so "Belgian
> mapping standards". These would hopefully be followed internationally, but
> we have to start somewhere. This would build especially on the thoughts of
> Marc and Julien on the subject and would ideally result in a Belgian
> mapping standards on the wiki.
> - define usecases for the dataset Julien Radoux is providing, and make
> sure that everything is OK to make that happen
> - what you bring to the table
>
> To move forward, I would like to propose having a (virtual) meeting about
> the subject. Who would be interested in participating? We could have a real
> meeting (probably in Brussels or Namur) with some people participating
> online.
>
> 1: https://cdn.rawgit.com/nobohan/OSMLanduseAnalyzer/
> 9a8b0290/presentation/2017_10_26_FOSS4G.be_OSMLanduse/index.html#/
> 2: http://www.lifewatch.be/en/lifewatch-wb-ecotope-database
>
> --
> 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] Digital Globe Images

[Lionel Giard]

Yes it seems to be a little bit more recent than 2015 SPW imagery in
Chaumont area (like a few month between the two). But the main disadvantage
is that the pixel size seems to be higher in Digital Globe imagery (the
image looks coarser). Bing still is the clearest imagery of all (with the
high constrast that help recognize the items). Would like to get a recent
imagery of Wallonia with good contrast like Urbis or AGIV ahah.

2017-05-12 12:40 GMT+02:00 Thibaut Philippart 
:

> Hello
>
> The imagery seems to be also more recent than SPW (less than 1 year in LLN
> and Chaumont area ; I didn't check in other areas).
>
> Yep, definitely useful !
>
> Thibaut
>
> On May 12, 2017 8:51 AM, joost schouppe  wrote:
>
> Yes, they even seemed to prioritize areas which had no decent coverage at
> all. For example, I checked my "area of interest" in Bolivia, and there's a
> lot of new woods to map (I like to following the outline of civilization):
>
> http://www.openstreetmap.org/#map=12/-17.3651/-65.2039
>
> Tais just pointed out that in Congo as well, some places are now mapable
> that weren't before. So if you had some areas of interest that had bad
> imagery before, now you will probably have something better.
>
> As for Belgium: the imagery seems to be much more recent than Bing, check
> for example here:
>
> http://www.openstreetmap.org/edit#map=18/50.63689/4.17203
>
> I for one am not going to use SPW imagery until we have a more official
> letter from them, so for my Walloon mapping, this is definitely useful.
>
>
> --
> Joost Schouppe
> 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] Land-use mapping with OSM in Belgium

[Lionel Giard]

That's definitely an interesting answer. It seems that dividing the large
landuse=residential is something that we should do (as it seems logical,
even if can be tedious sometimes).

I did some digging into the wiki for trees tagging and came to these
conclusions. When we think about the key definition of landuse
<http://wiki.openstreetmap.org/wiki/Key:landuse>, landcover
<http://wiki.openstreetmap.org/wiki/Landcover> (including its proposed page
<http://wiki.openstreetmap.org/wiki/Proposed_features/landcover>) and
natural <http://wiki.openstreetmap.org/wiki/Key:natural>, i came to the
conclusion that the only landuse tag for tree is "landuse=forest". Because
the key "natural" is described as a landcover representation. It seems that
natural=wood is one of the only special case where a natural tag does
represent landuse in common usage (and it seems wrong relatively to the
definition).

If we follow strict definition, the only landuse tag for trees/forest is
"landuse=forest". The others are for landcover (like the proposed
landcover=trees). Should we then be conservative and use only
landuse=forest in Belgium (especially because the definition for
natural=wood is very rare for us) ? And use landcover tag on top of others
landuses if needed (like for tree in parks).

Following all these definition note that landuse include the keys
landuse=*,  amenity=*, leisure=* and tourism=* all as landuse
representation, it implies that we should also remove the
landuse=residential (or any other) where we have something like
amenity=school (because it is already a landuse that probably better fit
than the landuse=residential).  What do you think about that ?

2017-04-28 22:16 GMT+02:00 Marc Gemis <marc.ge...@gmail.com>:

> Here is one answer I got, Martin was so kind to put it into a diary
> entry: http://www.openstreetmap.org/user/dieterdreist/diary/40993
>
> On Fri, Apr 28, 2017 at 3:19 PM, Marc Gemis <marc.ge...@gmail.com> wrote:
> > On Fri, Apr 28, 2017 at 2:23 PM, Lionel Giard <lionel.gi...@gmail.com>
> wrote:
> >> But for the roads, ideally, it should ideally be an area (like on the
> GRB of
> >> Vlaandereen or the PICC of Wallonia) with also the existing line to
> allow
> >> routing. I don't know, if we must change existing residential area when
> >> adding area for the road, because it will probably look good on the
> map, but
> >> maybe it would be a problem for people using the data ?! At least it
> >> shouldn't be a problem for the big highways, because they often don't
> have
> >> landuse at the moment (look at http://osmlanduse.org/ ).
> >
> > as long as you keep the current way for navigation, and just add
> > area:highway there is no problem.
> > Just follow the area:highway instructions on the wiki and the
> > navigation will not get broken. I experimented with in on a small area
> > and navigation still works.
> >
> > I contacted 2 mappers that map landuse in great detail (one in
> > Germany/Italy, one in Japan) and asked them for some samples.
> > I doubt that multipolygons are the way forward, too complex to
> > maintain I fear. We should look at detailed areas in e.g. Germany and
> > see how they do it.
> >
> >
> > m
>
> ___
> 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] Land-use mapping with OSM in Belgium

[Lionel Giard]

I understand your point, and that's why we should say if something must be
done or not : describing the best practices.
For landuse inside an existing residential area, it is always possible to
just change the residential zone into a multipolygon relation and make the
new landuse (like the park) an inner polygon. So it will still display the
same on the map, but will not count as having two landuse at the same
place. It avoids to tediously redraw a large residential area.

But for the roads, ideally, it should ideally be an area (like on the GRB
of Vlaandereen or the PICC of Wallonia) with also the existing line to
allow routing. I don't know, if we must change existing residential area
when adding area for the road, because it will probably look good on the
map, but maybe it would be a problem for people using the data ?! At least
it shouldn't be a problem for the big highways, because they often don't
have landuse at the moment (look at http://osmlanduse.org/ ).

About the area you linked, I really don't have a definitive answer, is the
wooded area part of the garden of the houses ? Maybe do a mix of
landuse=residential and landuse=forest/lancover=trees (to have the house
and garden not included in the forest) ?
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Land-use mapping with OSM in Belgium

[Lionel Giard]

Personally, i put Nature reserve on a special relation, as it is described
on the wiki, like this one :
http://www.openstreetmap.org/relation/7130732#map=17/50.68519/4.70461
And the forest or other landuses are just part of this multipolygon. In
this example, i also have a multipolygon for the forest because, i have
things inside it.
Nothing stop you to have multiple relation at the same place (i think of
relation like a "special" polygon, and nothing stop us to make multiple
polygon on each other but slightly different in shape).

We should really describe/decide which tag is representing a landuse
(because it can be landuse=*, leisure=* or natural=*) and if we need to
avoid putting them at the same place (like allow or not leisure=park on top
of landuse=residential ?!). Right know, we all have our own opinion and it
create some variation of the map in Belgium.
And we should avoid gap in the landuse. Thus it seems important to solve
some problems like what should be the landuse tag under a road ?

2017-04-27 14:29 GMT+02:00 Marc Gemis :

> On Thu, Apr 27, 2017 at 1:50 PM, joost schouppe
>  wrote:
> > The examples you give are already hard work to think about. Much more
> basic
> > mistakes are made too: e.g. a forest is also a nature reserve. But then
> > someone turns the forest into a multipolygon, because there is some
> water or
> > grassland inside of it. But the multipolygon is also used for the nature
> > reserve. Which would imply the holes in the forest are unprotected, and
> > that's usually not the case.
>
> I have been thinking about this as well. even the name belongs to the
> outer way and not the relation.
> I would say put the nature reserve tag on the outer way and the forest
> tags on the relation. Would that work ?
>
> But tagging mistakes due to bad quality aerial imagery is equally
> common I think. And those are much harder to detect I think.
> For your case, it  is basically looking up all multipolygons on which
> the nature reserve tags is placed and check those. While this can be a
> long list, it is not nearly as long as checking all landuses.
>
>
>
> m
>
> ___
> 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] Land-use mapping with OSM in Belgium

[Lionel Giard]

Hi,

Concerning the wood-tag : I was personally using the first approach Here
 where it says that
natural=wood is for area covered by tree, and natural=forest is for area
managed for land forestry (like plantation in the Ardennes). And most of
the time, the only "wood" areas are the place around motorway intersections
for example (between the roads, you often have an area covered by tree,
without real management).

I agree with you about fenced area that correspond to pasture/meadow. But I
would also include, based on local knowledge only, some non-fenced area as
landuse=meadow when it is an area for cutting only (to feed cattle for
example) like it is often the case in some part of Wallonia. It's sometimes
area that are unsuitable for agriculture, but used just to feed cattle
without letting them graze on it (like when it is too dangerous).
And for any uncultivated area, composed of mostly grasses and herbaceous,
there always is the natural=grassland
 tag.

Every other cultivated area, should then only be orchard or farmland. The
only problem can be when a combination of different types of agriculture
occur at the same place, then i don't know how to map.

Lionel

Garanti
sans virus. www.avast.com

<#m_-9078182235892435705_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2017-04-25 11:40 GMT+02:00 Gerard Vanderveken :

> Hi,
>
> One remark for the wood-tag:
> The tag natural=wood
>  is sometimes
> used for forests, but since natural=wood would refers to unmanaged, natural
> forests, IMHO it should not be used in Belgium since no more forests are
> completely natural: every patches of forest in Belgium has experienced
> human interventions in the recent history.
> In several forests Zoniënwoud, Meerdaalwoud, ... are some nature reserves.
> Places where nature can have its course and where only very minimal human
> intervention take place (eg clearance of paths)
> I think these reserves (Joseph Zwaenepoel, Kerselaerplein, Everzwijnbad,
> Pruikemakers) could qualify as wood.
>
> I think meadow is a good tag for the grass lands. Conversion between
> farmland and grass land takes somtetimes place but mosttimes as incidental
> crop harvest of grass.
> Making a pasture requires also fencing, which is not a temporary measure.
>
> So, when there is a grass land without fence surrounded by farmland, it is
> likely farmland.
> Other grass lands are usually fenced and are meadow.
> Local knowledge will tell if it is to be one or the other
>
> Regards,
> Gerard.
>
> Julien Minet wrote:
>
> Hi list,
>
> Following some discussions about landuse=farmland|meadow some times ago in
> this list, I've written an article here (http://www.nobohan.be/2017/
> 04/20/landuse-osm-belgium/) about land-use mapping in Belgium: what could
> be the best practices adapted to the Belgian landscape. Of course, there's
> matter for discussions about that topic ;-)
>
> I think this text could be used to make a page on
> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/,
> since it discuss what are the local conventions for land-use mapping in
> Belgium.
>
> Do you also want to put this text on osm.be, similarly to the Marc Gemis
> articles? Maybe a better place for discussions...
>
> Cheers,
>
> Julien
>
> --
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://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] Fwd: [OSM-talk] Upcoming removal of landuse=farm in the standard style

[Lionel Giard]

In Wallonia, we are currently working at redoing most of the old stuff and
correcting errors, and landuse=farm is part of them. As we don't have good
landuse coverage, it is probably better to just not render these old "farm"
polygon (most of them overlap other zones or are badly traced). And we will
change it progressively.

2017-03-22 15:44 GMT+01:00 Marc Gemis :

> On Wed, Mar 22, 2017 at 3:03 PM, joost schouppe
>  wrote:
> > In Flanders, the convention seems to be landuse=meadow for grazing lands,
> > and landuse=farmland for growing plants. That's not according to what the
> > wiki says (farmland could be grazing land). But it does make it easy to
> > differentiate. I don't really care what tags we choose. But I wonder if
> we
> > could tag things so that it stays easy to recognize "agricultural land of
> > which we're not sure whether it is grazing land or plant-growing land".
>
> You mean in case you are looking at an aerial image and want to colour
> a part of the map ?
> Or is this also a problem in case you surveyed the area on the ground ?
>
> I just had to fix a few farmlands with orchard and plant_nursery, so I
> am very sensitive to incorrect mapping landuse based on aerial images.
>
> I rather see it not rendered at all on the map than with a wild guess
>
> m.
>
> p.s. from the landuse=farmland wiki page "Also note that many mappers
> prefer the more specific tags landuse=meadow for meadows and pastures
> (what is labelled landuse=farmland in the picture), landuse=orchard
> for fruit orchards, and use landuse=farmland for cropland only."  I
> assume this line was not added only for Belgium :-)
>
> p.p.s. on the German versions of the farmland page, no one mentions
> that it can be used for meadows  (although the use the same picture)
> "landuse=farmland kennzeichnet eine Ackerfläche. Äcker werden zum
> landwirtschaftlichen Feldfruchtanbau und zum erwerbsgärtnerischen
> Blumen- und Gemüseanbau genutzt.
>
> Für Grünland zur Tierweide oder Heugewinnung sollte landuse=meadow
> gewählt werden."
>
> ___
> 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

[OSM-talk-be] mapper meeting in Louvain-la-Neuve/reunion de mappeurs à Louvain-la-Neuve 24/03

[Lionel Giard]

Hello,

We've just created the meetup for the next meetup in LLN (Louvain-la-Neuve)
on Friday the
24st of March at La Crêperie Bretonne - La Mère Fillioux (remember ->
delicious pancake and beer !), I hope it will attract more people ! ;-)

Everybody is more than welcome to come!

https://www.meetup.com/fr-FR/OpenStreetMap-Belgium/events/238062854/

Looking forward seeing you there!

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

[OSM-talk-be] Mapper meeting in Louvain-la-Neuve next month

[Lionel Giard]

Hello,

We've just created a framadate to prepare the next meeting in
Louvain-la-Neuve (our first meeting in Wallonia i think). If you want to
come, please indicate when you are free on the link below (among a
selection of date). It will probably be at "La Crêperie Bretonne" (->
délicious pancake !), I hope it will attract more people ! ;-)

Public link : https://framadate.org/hf8piHIwOIzL871S

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

[OSM-talk-be] a new National Mapathon - call for volunteers

[Lionel Giard]

Hi Joost,

I'll be happy to volunteer at *UCL (Louvain-la-Neuve) ! :-)*

I can help to everything as i'm used to work with hotosm/id/... and
mapathon in general (*MSF mapathon T-shirt owner club inside :p*).

Lionel Giard

*De :* joost schouppe [mailto:joost.schou...@gmail.com]
*Envoyé :* vendredi 3 février 2017 08:40
*À :* OpenStreetMap Belgium <talk-be@openstreetmap.org>
*Objet :* [OSM-talk-be] a new National Mapathon - call for volunteers



Hi,



Last year, the Interuniversity National Mapathon was a great success: about
200 people in seven universities participated, and we got in the 7 pm news
issue of both VRT and VTM.

OSM-Be volunteers supported all seven events.



The next national mapathon is being planned right now, and they want our
help again!



We will need volunteers at ULB (Brussels), VUB (Brussels), UCL
(Louvain-la-Neuve), KUL (Leuven), Ugent, ULG (Liege), UNamur. Four more
cities might still join in the following days.



Previous experience with humanitarian mapping, iD and the Tasking Manager
is of course welcome, but we will give you some training too. Last year, it
wasn't easy finding volunteers for all places, but it is important that
there is an experienced mapper at all of these places.



Basically we need you for any or all of these tasks:

- give an introduction about (humanitarian) OSM, a short training

- just being around and helping people with questions

- validating (even from home) during the event, so we can correct newbie
mappers before they make the same mistake a thousand times



Just send me a mail with your preferred tasks and city (or cities) and
we'll be in touch.



--

Joost Schouppe

OpenStreetMap <http://www.openstreetmap.org/user/joost%20schouppe/> |
Twitter <https://twitter.com/joostjakob> | LinkedIn
<https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup
<http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>

___
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