GSM-antennes getagd als man_made=tower

In Nederland zijn (bijna) alles gsm-antennes getagd als man_made=tower, zie overpass.

Volgens de wiki is man_made=tower toch wel bedoeld voor behoorlijk forse torens, dus niet voor een mastje op een dak van een huis.

We zijn van plan binnenkort de tag man_made=tower te gaan renderen op de standaard rendering. Met de huidige tagging zou dat betekenen dat heel Nederland vol komt te staan met torens waar ze niet thuis horen.

Ik zou de Nederlandse gemeenschap daarom aan willen raden dit tagging probleem op te lossen. Dit voorstel, dat niet in stemming is gebracht maar wel goed in elkaar lijkt te zitten, kan daarmee misschien helpen.

Ik heb me hier ook wel eens over zitten verbazen, incidenteel verander ik de tag nog wel eens naar man_made=mast, maar alleen als er ook echt een mast staat, want ook gsm antennes die aan een gebouw bevestigd zijn hebben de toren tag. Verder zijn er situaties te vinden waarin 3 verschillende antennes als 4 verschillende torens getagd zijn. Bovendien is de locatie van de masten niet heel precies. Naar mijn mening is de kwaliteit van deze data zo waardeloos dat osm beter af is als deze gewoon botweg verwijderd word.

Misschien is het een goed idee om alle antenne data te vervangen voor een verse import van http://www.antennebureau.nl/ of http://www.gsmmasten.nl/. iemand?

Dit voorstel ziet er idd goed uit. laten we het gebruiken. (alles beter dan de huidige situatie :wink: )

Lijkt me inderdaad een goed idee, maar gaan we dat handmatig doen of gooien we er een “mechanical” tegenaan?
Enige tijd geleden hebben we op die manier de overbodige AND tags aangepakt.
Daarbij ontstond wel weer discussie over het verloren gaan van de geschiedenis enz. enz.
Ik heb toen alle tags waar mijn naam in de geschiedenis stond aangepakt. Maar ik heb geen enkele zendmast op de kaart gezet, dus mijn bijdrage zou dit keer vrij klein zijn…

Prima plan om al die torens aan te pakken, ik gooi alle man_made=tower & tower:type=communication standaard uit mijn kaart vanwege de overkill aan torens.

Math1985, komen dan al die antennes dan ook bij elkaar op een toren of mastje :slight_smile: Goed idee nu is dat een verschrikking, hier een mast en 20 m. verder nog een :frowning: Ik heb ze weleens geordend middels een notatie, maar daar werd scheef naar gekeken met het commentaar niet aankomen is van een import ? Antennes zijn uit mijn werkveld verdwenen en ik neem slechts de toren en de omheining mee.

3 weken geleden

Daarna werd het - op een paar reacties na - weer stil.
Dat zie je wel vaker gebeuren in structuren die in feite zonder duidelijke aansturing functioneren en waarbij niemand zich verantwoordelijk voelt voor een eindresultaat waar persoonlijke voorkeuren geen rol spelen.

Mijn vraag is heel simpel:
Waarom lossen we dit niet op door domweg al die verkeerd getagde zendmasten middels een mechanical edit te voorzien van de juiste tags?
Zo moeilijk is dat niet, maar waarom gebeurt het niet?

Hi Marc,

Tja ik heb daar ook wel eens aan gewerkt, er zitten tenslotte meerdere antennes aan een mast en er staan niet 4 masten :/. Maar werd terug gefloten met het argument, maak er geen notering van want het is import :frowning:
Hoe moet je anders 4 masten (zenders) samenvoegen op een plaats, dan met een wetenschappelijk aanvaarde notering ?
Na die edit zijn we gelijk die losse nodes in een weiland kwijt die ergens verloren staan te zijn.

Als we niets doen, dan is dus dit het beeld binnenkort, allemaal torens die geen torens zijn.
Precies waar Math1985 voor waarschuwt.

Afgaande op deze discussie:

https://github.com/gravitystorm/openstreetmap-carto/pull/1366#issuecomment-81632042

en op het feit dat tijdens de recente update van de Cartostyle (zie forum) inderdaad de torens buiten deze stijlaanpassing zijn gehouden, concludeer ik dat het gevaar voorlopig lijkt te zijn geweken.

@math1985, kun je dat bevestigen?

Marc, dat de verwarrende data mbt de masten niet in beeld komt, tja dat is hetzelfde als het stof onder het kleed vegen, zelfbedrog. De discrepantie tussen de verschillende import stromen in OSM blijft dus bestaan :confused:

Nee, we zouden de stijlaanpassing nog steeds graag doorvoeren. Wel wachten we het liefst met de stijlaanpassing tot de tagging in Nederland is aangepast. Zou iemand hier mee bezig kunnen gaan?

Ik zou de tagging ook zelf aan kunnen passen natuurlijk, maar ik denk dat het het netste is om aan een scheiding van machten aan te houden - het lijkt me democratischer als de tagging en de rendering niet onder controle staat van dezelfde persoon.

Dat betekent dat we wat moeten gaan doen!
Ik heb de situatie in Brabant verkend en heb via overpass turbo gekeken naar:

man_made=tower AND tower:type=communication

Om alle objecten te vinden die als toren EN als zendmast getagd zijn.
Dat leverde dit plaatje op: [overpass]

Vervolgens keek ik naar:

man_made=tower AND tower:type!~communication

Om de objecten te vinden die als toren MAAR NIET als zendmast waren getagd (voornamelijk kerktorens, maar ook windmolens enz.).
Dat leverde dit plaatje op: [overpass]

Wat we volgens mij moeten doen is om in alle gevallen waarin sprake is van

man_made=tower
tower:type=communication

dit om te zetten naar:

man_made=communications_tower

waarbij we de tag tower:type=communication verwijderen.

Dat zou het beste weer kunnen via een mechanical edit.

Zou iedere lezer van dit onderwerp bovenstaande tests ook uit willen voeren voor de provincie waarin men woont om te zien hoe daar het beeld is?

Je kunt in onderstaande scripts (maar ook in de overpass links die ik hierboven al gaf) je eigen provincie invullen.

Torens die als zendmast zijn getagd:


{{geocodeArea:Noord-Brabant}}->.searchArea;
// gather results
(
  node["man_made"="tower"]["tower:type"="communication"](area.searchArea);
);
// print results
out body;
>;
out skel qt;

Torens die niet als zendmast zij getagd:

{{geocodeArea:Noord-Brabant}}->.searchArea;
// gather results
(
  node["man_made"="tower"]["tower:type"!~"communication"](area.searchArea);
  way["man_made"="tower"]["tower:type"!~"communication"](area.searchArea);
);
// print results
out body;
>;
out skel qt;

Er blijven knelpunten in de door mij voorgestelde procedure en er zullen ongetwijfeld zendmasten verdwijnen die er eigenlijk wel moeten staan, en we zullen er ook een paar laten staan die weg moeten, maar ik denk dat we een aardige trefkans hebben met mijn voorstel.
Tegenvoorstellen zijn natuurlijk ook welkom, vooral op het gebied van een nauwkeuriger script voor de overpass turbo, waarmee mogelijk nog beter een juiste omzetting kan worden verkregen.

Iedereen die inmidels de nieuwe cartostyle van OSM heeft ervaren, heeft gezien dat er heel veel meer symbolen op de kaart verschijnen op de hoogste zoomniveaus. Het lijkt mij belangrijk genoeg om er voor te zorgen dat we het torenprobleem adequaat oplossen, anders zien we straks door de torens het bos niet meer!

Marc, als ik het goed begrijp komt de man_made tag dan te vervallen, terwijl het in sommige gevallen man_made=mast zou moeten worden. Om dit uit te sluiten zou je visueel mbv satelietbeelden moeten nagaan of de apparatuur aan een gebouw hangt of een eigen mast heeft. De mast hier een stukje verderop kan ik niet onderscheiden tussen de bomen van de satelietbeelden, dus dat kan nog best lastig zijn, zeker aangezien 10 meter verderop nog een node ligt en ik vrij zeker weet dat er maar 1 mast staat. Nog maar eens langs lopen een keer…
En dan wat te doen, wil geen 2 masten intekenen als het er maar 1 is en welk van de 2 nodes hang je eraan, of mergen naar 1 node? Moet het inzichtelijk blijven dat het meerdere apparatuurclusters zijn van iedere aanbieder?

En zo te zien zijn dat in Zuid-Holland dik 3100 locaties die beoordeeld moeten worden.
De 2e zoekvraag leverde ook nog een vuurtorens op (terwijl we ook nog man_made=lighthouse hebben en tower:type=lighting toch ergens anders voor bedoeld lijkt), maar lijkt dat het meerendeel van de ruim 400 ways/nodes terecht op man_made=tower als een aantal daarvan nader bekijk.

Een mechanical edit zal uiteindelijk meer verbeteren op het vlak van onterechte towers dan schade berokkenen aangezien in die gevallen het toch al niet goed staat. Enkel krijg je dan een andere verkeerde situatie, dus dat lijkt me zo op het eerste gezicht acceptabel.

Sander,

Als je daarmee alle antennes aan een mast wilt bundelen komt er denk ik nog een aardige discussie los. Die heb ik ooit over me heen gekregen, nadat ik antennes aan een mast ging bundelen naar hoogte en frequentie met een ; Dat kon en mocht niet :confused: Al die losse (geimporteerde en foutieve) antennes moesten los blijven staan of zweven. Om van hoog staande antennes op gebouwen maar niet te spreken, dat is of wordt lastig controleren want wie laat je op het dak of per drone, ik ben benieuwd naar de reacties.:rolleyes:

Als we de hoogte van de toren ook bij onze beslissing gebruiken, dan zou je bij torens > 100 meter van

man_made=communications_tower

moeten spreken en bij alles tot 100 meter van

man_made=mast

Ik zie alleen nog geen manier om de overpass te bevragen met een “>” teken omdat dat symbool al een eigen functie heeft binnen de overpass query-language.

Dus :

man_made=tower
height>100

zou ons aardig op weg helpen, maar werkt helaas niet.

Kun je in JOSM zoeken op waarden “groter dan”? Dan zou je het daar op kunnen lossen. Dat werkt misschien nog handiger, want je hebt dan mogelijk nog meer opties die je mee kunt nemen in het omzet-proces.

Edit: overigens wordt de height=* tag vrij consequent gebruikt. Ik zie in heel Nederland maar een stuk of 30 communicatie torens waarbij de hoogte niet is opgegeven.

Ik geef zelf even antwoord: Ja, dat kan. Dat betekent dat het hele omzettingsproces veel makkelijker valt te sturen.
Er blijken bv. in Brabant maar 2 echte communicatietorens te staan die hoger zijn dan 100 meter. De overige 790 “torens” zijn dus beter af met “mast”.

Weer een stap verder!

Marc, misschien een beetje laat, maar is toren versus mast afhankelijk van de hoogte of van de constructie ? Een mast is IMHO slechts een spriet, met een uitgebreide vakwerk constructie wordt het een beetje troebel, maar zelfs Smilde wordt wel eens mast genoemd er is dus een uitgebreide Wiki test of update nodig met een vertaling naar andere talen.

Dit wordt in (minstens) 2 wiki’s besproken:

http://wiki.openstreetmap.org/wiki/Proposed_features/Telecommunications_tower
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcommunications_tower

Wat mij betreft is die grens van 100 meter niet doorslaggevend, maar omdat de hoogte vaak het enige - bouwkundige - aspect is dat wordt gegeven, moeten we het daar waarschijnlijk wel mee doen.
Ik zal eens wat verder onderzoek doen om te zien welke zendmasten in Nederland die 100 meter grens halen of overschrijden.
Daarna kunnen we misschien tot een consensus komen over waar we de grens leggen.

Maar het is nu natuurlijk volkomen onzinnig om een mastje van 5 meter hoog op het dak van een postkantoor een “toren” te noemen.

Marc, 100 m zal me verbazen eerder <50 m en ja een mast van 5.00 m is een mastje :), maar ik denk dat er daar weinig van zijn. Te kwetsbaar of stormgevoelig en de richting en elevatie luisteren nauw, het zijn met de antennes eraan boven op t dak aardige windvangers.

Ik blijf dit een erg verwarrend verhaal vinden. Wat moet nu wel, wat moet niet?

Paar voorbeelden:
Ik zie in de buurt van mijn huis een schoorsteen met tags:
height=24;23;20
man_made=tower
technology=UMTS;GSM 900
tower:type=communication

ID=node 599572281
Mappers: Stefan de Konink en Woeka

Volgens het voorstel, dat in het eerste subject is aangehaald, moet dit dan worden:
man_made=chimney
communication:mobile_phone=gsm;umts

Waar dan die hoogte tag blijft is een raadsel en het voorstel wordt ook niet over GSM900 gesproken.

Nog dichter bij mijn huis staat een hoogspanningsmast met antennes eraan.
Het voorstel heeft het totaal niet over hoogspanningsmasten met antennes, maar volgens mij zijn die er meer in Nederland.
Daarbij lagen een paar van die antenne/toren tags in het water, maar die heb ik een tijd geleden weg gegooid.

Maar hetzelfde symbooltje wordt in JOSM ook gebruikt voor kerktorens, zoals in Colmschate:
brontype=luchtfoto
brt:datum=2005-01-01
brt:height_class=laagbouw
brt:id=NL.TOP10NL.117742637
brt:type=religieus gebouw,toren
man_made=tower
source=Kadaster
source_ref=http://www.kadaster.nl/web/Themas/Registraties/brt.htm
ID: node 2388549695
Mapper: milovanderlinden

Zuidwest van Bathmen staat een tamelijk grote mast met de volgende tags:
height=31
man_made=tower
technology=UMTS
tower:type=communication
ID: node 599583630
Mapper: Stefan de Konink

Er naast op de ijsbaan liggen nog 2 tags:
height=38;42
man_made=tower
technology=GSM 900;UMTS
tower:type=communication
ID: node 599583629
Mapper: Stefan de Konink, hvdwolf_BAG, pooico

height=32
man_made=tower
technology=GSM 900
tower:type=communication
ID: node 599572252
Mapper: Stefan de Konink
Deze twee tags bestaan buiten niet.