Re: [OSM-talk-be] BIPT antennas

[Vucodil via Talk-be]

Hi,

@Midgard

> Vucodil, where can I find the source for the advanced data about the 
> antennas, like the reference
> codes? In the list I downloaded from BIPT, I only find the coordinates.

I'm accessing a kind of endpoint/api (via javascript). When you click on 
"search for a site", insert nothing and search, you get a list of IDs.
In this case, you are accessing the same endpoint.

@Lionel

> One solution could be to map everything as telecom=antenna if they don't 
> match a mast/tower (already mapped), and put a "fixme=check if a mast or 
> tower is present". Note that on a rooftop, you generally don't have a mast 
> (it > is a small support structure that we can just consider being 
> "telecom=antenna" and maybe in the future, we could use a "antenna:support=*" 
> tag ;-) ).

ok so we could also check if the antenna is located on a osm building. If it is 
the case, the fix me should not be needed.

I will adapt the import proposal with what Lionel suggested and with the other 
suggestions. And then, I will bring it back to the mailing list.

Best regards

Vucodil

March 10, 2020 11:50:31 AM CET Lionel Giard  wrote:
@ Vucodil :
One solution could be to map everything as telecom=antenna if they don't match 
a mast/tower (already mapped), and put a "fixme=check if a mast or tower is 
present". Note that on a rooftop, you generally don't have a mast (it is a 
small support structure that we can just consider being "telecom=antenna" and 
maybe in the future, we could use a "antenna:support=*" tag ;-) ). [1]

For mast and tower, use the obvious existing one, or map it if it is visible 
(some of them can be easily seen on imagery), and use the man_made=mast or 
tower tag like usual and change it later on if needed (if a future proposal is 
done for it). :-p 

For man_made=antenna, i don't think it is better than telecom=antenna (neither 
one or the other was ever approved formally). The telecom key was created to 
refine the telecom tagging following the same idea that was used for the power 
infrastructure (with the power key). I'm completely in favor of redesigning the 
telecom infrastructure tagging like the french community started to push 
(especially focused on cable and fiber infrastructure at the moment), as they 
seem quite experienced with infrastructure tagging as they were involve in 
power tagging... :-p 
So using telecom=antenna seems more logical in order to already start using a 
"proper" tag instead of a general tag like man_made=antenna (that we could 
regret later on). And it can always be changed if/when someone do a proper 
proposal and approval process later on (as that would be the only difference, 
as the subkey will probably be identical).

antenna:use seems functionally equivalent to the subtag communication:*=yes/no 
(like communication:mobile_phone=yes/no). I don't see an improvement as the 
communication:*=yes/no is already used for all mast/tower (including 
power=tower ! As they can have antenna on them (i don't know if that's the case 
in Belgium)), so we should maybe use it for antenna too. ^_^ One example that i 
did map like that for an antenna (on top of a watertower here) was 
https://www.openstreetmap.org/node/5968512028 .  

[1] I work at one of our telecom company and i can see their structure data 
(pylons, mast, ...) and it is very detailed but unfortunately it is closed 
data.  :D But antenna on rooftop have a structure type : "self-supported roof 
structure". ;-) 
We should push BIPT to open more infrastructure data. :-D *dreaming* 

Le lun. 9 mars 2020 à 22:18, Vucodil via Talk-be  a 
écrit :

Hello everyone,

Already thanks for all the feedback! I answer some of your questions in the 
following topics:

Continuous update (@Midgard and @rodeo.be )

It was in the back of my head but I didn't want to plan it yet. I will probably 
work on that but not soon.
Note that the list of BIPT antennas is updated monthly. Is there server for 
scheduled scripts within OSM BE ?

Workflow (@Midgard)

The distance triggering manual review has been changed to 25m.

> 3) And even then, just dumping elements in OSM without manual review is not 
> considered best
   > practice, but since it's only nodes, things are relatively simple and I 
won't object. I would
   > just like to see that they're not placed too close to any other existing 
node, but that can be
   > checked automatically.

Like one meter? Is there JOSM tool for that?

BIPT (@Thibault Rommel)

I agree. I updated the proposal

Latitude and longitude as tag (@s8evq and @Midgard)

That's a mistake. I only wanted to explain that I use the longitude and 
latitude provided in the dataset. It has been updated.

Open data Portal (@rodeo.be)

Good idea. I will inform BIPT of the positive feedback of the OSM BE community 
and I will kindly push them to do so.

Precision of the localisation

Looking alone at 9000 nodes for manual review is quite some work. Would it be 
acceptable to have a FIXME tag stating that the localization

Re: [OSM-talk-be] tile.osm.be

[Marc M.]

Le 10.03.20 à 20:51, Jonathan Beliën a écrit :
> I need to start a powerful server to run the database update 
> and then the tiles update

this part is scripted ? a cloud server ?
what's the hd size, type (hdd<>sdd) and number of cpu cores  needed
to update all tiles in one day ?

Regards,
Marc

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

Re: [OSM-talk-be] tile.osm.be

[Jonathan Beliën]

Hello Maarten,

Indeed, I'm the one maintaining https://tile.openstreetmap.be/
And indeed, it hasn't been updated since a few months now.

I've put that tileserver online for the use of the company I work for (SPRL 
GEO-6 BVBA) and I convinced my boss to make it publicly available and make it 
the official OSMBE tileserver (thus the copyright referencing GEO-6).

The update process is indeed not fully automated : I need to start a powerful 
server to run the database update and then the tiles update (in 3 versions : 
`name` + `name:fr` + `name:nl`) and the whole process takes a whole day to 
complete.
The update is not live because we (GEO-6) decided not to invest such a "big" 
amount of money in a server that could handle a live (or at least regular) 
automated update (and the current tilserver is still one of the biggest - 
meaning more expensive - server we manage and pay for).
Unfortunately, those last few months have been quite busy and I didn't have (or 
at least didn't take) the time to run the update.

So, yes, the service *will stay online* and we are not planning to discontinue 
it !
The update is a "best-effort" update and I'll try to update it as regularly as 
possible (but without any guarantee).

That being said, I'm also investigating some other solutions for the OSMBE 
tileserver to simplify the update but didn't find any suitable solution so far 
(adding vector tiles is also part of my research).

Any suggestion or proposal of help is more than welcome !

Have a nice evening.

Jonathan Beliën
OpenStreetMap Belgium


Mar 10 mars 2020, à 11:35, Tim Couwelier a écrit :
> As I understood from Jonathan, the process isn't fully automated yet. Was 
> supposedly to get updated on a near-weekly basis, but it must've slipped from 
> attention.
> I'd guess that moving on towards a full automation of the process would go a 
> long way?
> 
> Op di 10 mrt. 2020 om 11:05 schreef rodeo .be :
>> Hey all,
>> 
>> I see this tile server has not been updated the last months. Is the future 
>> of that tile service unsure?
>> 
>> Btw, we asked several organiations to use those tiles in the past (see here 
>> ): "*Met 
>> OpenStreetMap Belgium hebben we in samenwerking met een sponsor een 
>> tile-server optgezet die wel expliciet bedoeld is om te gebruiken in uw 
>> situatie.*" 
>> 
>> I think it would be worth it to keep that service! How can we help?
>> 
>> KR
>> Maarten
>> ___
>>  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

[Gert Van Oost]

Hey,

I’m new at OSM so I don’t know if this is an usfull contribution but the 
BIPT-antennes or updated in de WMS /WFS of the flemish governement at Mercator 
WMS /WFS at the layer ‘Zendantennes’

Wms : 
https://www.mercator.vlaanderen.be/raadpleegdienstenmercatorpubliek/ows?SERVICE=WMS

wfs : 
https://www.mercator.vlaanderen.be/raadpleegdienstenmercatorpubliek/ows?SERVICE=WFS

download –zip-shape : 
https://www.mercator.vlaanderen.be/raadpleegdienstenmercatorpubliek/us/ows?service=WFS&version=2.0.0&request=GetFeature&typeName=us_zndant_pnt&maxFeatures=4&outputFormat=SHAPE-ZIP

metadata :
https://www.mercator.vlaanderen.be/zoekdienstenmercatorpubliek/apps/tabsearch/index.html?uuid=00b8c6b6-437d-4d35-9b39-7ad300f11b94&hl=dut

best regards

Gert

Van: Lionel Giard [mailto:lionel.gi...@gmail.com]
Verzonden: dinsdag 10 maart 2020 11:51
Aan: Vucodil; OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] BIPT antennas

@ Vucodil :
One solution could be to map everything as telecom=antenna if they don't match 
a mast/tower (already mapped), and put a "fixme=check if a mast or tower is 
present". Note that on a rooftop, you generally don't have a mast (it is a 
small support structure that we can just consider being "telecom=antenna" and 
maybe in the future, we could use a "antenna:support=*" tag ;-) ). [1]

For mast and tower, use the obvious existing one, or map it if it is visible 
(some of them can be easily seen on imagery), and use the man_made=mast or 
tower tag like usual and change it later on if needed (if a future proposal is 
done for it). :-p

For man_made=antenna, i don't think it is better than telecom=antenna (neither 
one or the other was ever approved formally). The telecom key was created to 
refine the telecom tagging following the same idea that was used for the power 
infrastructure (with the power key). I'm completely in favor of redesigning the 
telecom infrastructure tagging like the french community started to push 
(especially focused on cable and fiber infrastructure at the moment), as they 
seem quite experienced with infrastructure tagging as they were involve in 
power tagging... :-p
So using telecom=antenna seems more logical in order to already start using a 
"proper" tag instead of a general tag like man_made=antenna (that we could 
regret later on). And it can always be changed if/when someone do a proper 
proposal and approval process later on (as that would be the only difference, 
as the subkey will probably be identical).

antenna:use seems functionally equivalent to the subtag 
communication:*=yes/no
 (like communication:mobile_phone=yes/no). I don't see an improvement as the 
communication:*=yes/no is already used for all mast/tower (including 
power=tower ! As they can have antenna on them (i don't know if that's the case 
in Belgium)), so we should maybe use it for antenna too. ^_^ One example that i 
did map like that for an antenna (on top of a watertower here) was 
https://www.openstreetmap.org/node/5968512028 .

[1] I work at one of our telecom company and i can see their structure data 
(pylons, mast, ...) and it is very detailed but unfortunately it is closed 
data. :D But antenna on rooftop have a structure type : "self-supported roof 
structure". ;-)
We should push BIPT to open more infrastructure data. :-D *dreaming*


Le lun. 9 mars 2020 à 22:18, Vucodil via Talk-be 
mailto:talk-be@openstreetmap.org>> a écrit :
Hello everyone,

Already thanks for all the feedback! I answer some of your questions in the 
following topics:

Continuous update (@Midgard and @rodeo.be )

It was in the back of my head but I didn't want to plan it yet. I will probably 
work on that but not soon.
Note that the list of BIPT antennas is updated monthly. Is there server for 
scheduled scripts within OSM BE ?

Workflow (@Midgard)

The distance triggering manual review has been changed to 25m.

> 3) And even then, just dumping elements in OSM without manual review is not 
> considered best
> practice, but since it's only nodes, things are relatively simple and I won't 
> object. I would
> just like to see that they're not placed too close to any other existing 
> node, but that can be
> checked automatically.

Like one meter? Is there JOSM tool for that?

BIPT (@Thibault Rommel)

I agree. I updated the proposal

Latitude and longitude as tag (@s8evq and @Midgard)

That's a mistake. I only wanted to explain that I use the longitude and 
latitude provided in the dataset. It has been updated.

Open data Portal (@rodeo.be)

Good idea. I will inform BIPT of the positive feedback of the OSM BE community 
and I will kindly push them to do so.

Precision of the localisation

Looking alone at 9000 nodes for manual review is quite some work. Would it be 
acceptable to have a FIXME tag stating that the localization could be a few 
meters offset? Or is it considered to pollute the OSM db

Re: [OSM-talk-be] BIPT antennas

[Lionel Giard]

*@ Vucodil :*
One solution could be to map everything as telecom=antenna if they don't
match a mast/tower (already mapped), and put a "fixme=check if a mast or
tower is present". Note that on a rooftop, you generally don't have a mast
(it is a small support structure that we can just consider being
"telecom=antenna" and maybe in the future, we could use a
"antenna:support=*" tag ;-) ). *[1]*

For mast and tower, use the obvious existing one, or map it if it is
visible (some of them can be easily seen on imagery), and use the
man_made=mast or tower tag like usual and change it later on if needed (if
a future proposal is done for it). :-p

For man_made=antenna, i don't think it is better than telecom=antenna
(neither one or the other was ever approved formally). The telecom key was
created to refine the telecom tagging following the same idea that was used
for the power infrastructure (with the power key). I'm completely in favor
of redesigning the telecom infrastructure tagging like the french community
started to push (especially focused on cable and fiber infrastructure at
the moment), as they seem quite experienced with infrastructure tagging as
they were involve in power tagging... :-p
So using telecom=antenna seems more logical in order to already start using
a "proper" tag instead of a general tag like man_made=antenna (that we
could regret later on). And it can always be changed if/when someone do a
proper proposal and approval process later on (as that would be the only
difference, as the subkey will probably be identical).

antenna:use seems functionally equivalent to the subtag
communication:*=yes/no

(like communication:mobile_phone=yes/no). I don't see an improvement as the
communication:*=yes/no is already used for all mast/tower* (including
power=tower ! *As they can have antenna on them (i don't know if that's the
case in Belgium)*)*, so we should maybe use it for antenna too. ^_^ One
example that i did map like that for an antenna (on top of a watertower
here) was https://www.openstreetmap.org/node/5968512028 .

*[1]* I work at one of our telecom company and i can see their structure
data (pylons, mast, ...) and it is very detailed but unfortunately it is
closed data. :D But antenna on rooftop have a structure type :
"self-supported roof structure". ;-)
We should push BIPT to open more infrastructure data. :-D **dreaming* *


Le lun. 9 mars 2020 à 22:18, Vucodil via Talk-be 
a écrit :

> Hello everyone,
>
> Already thanks for all the feedback! I answer some of your questions in
> the following topics:
>
> *Continuous update (@Midgard and @*
> *rodeo.be  )*
>
> It was in the back of my head but I didn't want to plan it yet. I will
> probably work on that but not soon.
> Note that the list of BIPT antennas is updated monthly. Is there server
> for scheduled scripts within OSM BE ?
>
> *Workflow (@Midgard)*
>
> The distance triggering manual review has been changed to 25m.
>
> > 3) And even then, just dumping elements in OSM without manual review is
> not considered best
> > practice, but since it's only nodes, things are relatively simple and I
> won't object. I would
> > just like to see that they're not placed too close to any other existing
> node, but that can be
> > checked automatically.
>
> Like one meter? Is there JOSM tool for that?
>
> *BIPT (@**Thibault Rommel)*
>
> I agree. I updated the proposal
>
> *Latitude and longitude as tag (@s8evq and **@Midgard**)*
>
> That's a mistake. I only wanted to explain that I use the longitude and
> latitude provided in the dataset. It has been updated.
>
> *Open data Portal (@rodeo.be )*
>
> Good idea. I will inform BIPT of the positive feedback of the OSM BE
> community and I will kindly push them to do so.
>
> *Precision of the localisation*
>
> Looking alone at 9000 nodes for manual review is quite some work. Would it
> be acceptable to have a FIXME tag stating that the localization could be a
> few meters offset? Or is it considered to pollute the OSM db to do so?
>
> *Tagging (@Lionel**, @Karel Adams, @midgard)*
>
> If I had found the discussion from 2018 before, I would have maybe not
> prepared the import :-D.
>
> *What to map?*
>
> The BITP dataset include a list of sites used in our mobile phone network.
> Each site can include multiple supports for antennas. And each support can
> include multiple directional antennas.
> There is no info on the support in the dataset. That's why I focused on
> mapping the antennas (or the group of antennas). Are they enough visible in
> our landscape?
> I think so. On rooftop in cities, those groups of antennas are often
> visible. 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.ht

Re: [OSM-talk-be] tile.osm.be

[Tim Couwelier]

As I understood from Jonathan, the process isn't fully automated yet. Was
supposedly to get updated on a near-weekly basis, but it must've slipped
from attention.
I'd guess that moving on towards a full automation of the process would go
a long way?

Op di 10 mrt. 2020 om 11:05 schreef rodeo .be :

> Hey all,
>
> I see this tile server has not been updated the last months. Is the future
> of that tile service unsure?
>
> Btw, we asked several organiations to use those tiles in the past (see
> here ):
> "*Met OpenStreetMap Belgium hebben we in samenwerking met een sponsor een
> tile-server optgezet die wel expliciet bedoeld is om te gebruiken in uw
> situatie.*"
>
> I think it would be worth it to keep that service! How can we help?
>
> KR
> Maarten
> ___
> 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] tile.osm.be

[rodeo .be]

Hey all,

I see this tile server has not been updated the last months. Is the future
of that tile service unsure?

Btw, we asked several organiations to use those tiles in the past (see here
): "*Met
OpenStreetMap Belgium hebben we in samenwerking met een sponsor een
tile-server optgezet die wel expliciet bedoeld is om te gebruiken in uw
situatie.*"

I think it would be worth it to keep that service! How can we help?

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