OpenCellID

[kdano]

Köszi!
Elsősorban az érdekelt, hogy ez szándékos-e, vagy valami automatizálási 
hibából származik. De akkor meg fogom mondani az osmose-nak, hogy false 
positive :)

Viszont így, hogy a szerkezetet is értem egy kicsit, van egy 
kérdésem/felvetésem:
Az felmerült, hogy más delimitert használjatok? Mert az én értelmezésem 
szerint a pontosvesszőt 
<http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator> inkább 
olyan esetben szokás használni, amikor az x címkének az y és z is értéke, 
és az "x=y" és "x=z" tageket vonjuk össze "x=y;z"-vé (vagy "x=z;y"-ná). 
Szóval ahol az érték egy halmaz, nem pedig egy lista.
A sávok tagelésénél <http://wiki.openstreetmap.org/wiki/Key:turn:lanes> pl. 
a "|" karakterrel elválasztott listákat használunk.
Ennek mintájára lehetne pl. 
lte:cellid=1;2;3|1;2;3|0;1;2;11 vagy 
umts:PSC=263|264|263|264|263|264 és 
umts:cellid=9021|9022|9026|9027|36996|36997

Persze nekem mindegy, csak miattam ne változtassatok: én nem tervezem sem a 
felvitelét, sem a felhasználást ezeknek az adatoknak. :)
Csak a konzisztencia miatt vetettem fel

üdv:
kdano


On Thursday, November 5, 2015 at 7:49:31 AM UTC+1, Kolesár András wrote:
>
> Szia!
>
> Két oka is van az ismétlődő adatoknak. Közös bennük, hogy egy-a-többhöz 
> relációt próbálunk kilapítva ábrázolni helytakarékosan és mégis olvashatóan.
>
> Az umts:PSC esetében egy az egyes cella-azonosítókhoz tartozó PSC 
> értékeket soroljuk fel, ezek tudnak azonosak lenni egy adott helyszínen, 
> sőt jellemzően háromszor ismétlődnek, ettől lesz a hálózat HSPA+.
>
> Az lte:cellid azért tud azonos lenni, mert a "; " elválasztójel két 
> oldalán különböző szolgáltatók celláit látod. A sima ";" egy szolgáltató 
> celláit határolja, a pontosvessző-szóköz az egy helyen működő 
> szolgáltatókat választja el egymástól. Ez utóbbi jelölésmódot azért 
> találtuk ki, hogy ne kelljen szolgáltatónként címkézni mindent. Így is 
> rengeteg címkét teszünk a tornyokra, ez háromszorozódna, ha 
> lte:cellid:21601=* formában szétbontanánk szolgáltatókra.
>
> Ha az objektumoknál lehetne relációkat vagy JSON-szerű hierarchiát 
> ábrázolni, akkor nyilván abban írnánk le.
>
> Íme egy bázisállomás egy szolgáltatóval, két irányban, irányonként három 
> cellával:
> http://cellavadasz.openstreetmap.hu/#map=14/47.4990/19.0564&id=3765523113
>
> MCC=216
> MNC=01
> gsm:LAC=3112
> gsm:cellid=9021;9022
> lte:LAC=5121
> lte:cellid=1;2
> lte:eNB=902
> umts:LAC=4121
> umts:PSC=263;264;263;264;263;264
> umts:RNC=412
> umts:cellid=9021;9022;9026;9027;36996;36997
>
> Ezt JSON szerkezetben az alábbit jelenti (csupa kisbetűs kulcsokkal és 
> numerikus értékekkel):
>
> {
>     mcc: 216
>     mnc: 1,
>     gsm: {
>         lac: 3112,
>         cells: [
>             { id: 9021 },
>             { id: 9022 }
>         ]
>     },
>     umts: {
>         lac: 4121,
>         rnc: 412,
>         cells: [
>             { id: 9021, psc: 263 },
>             { id: 9022, psc: 264 },
>             { id: 9026, psc: 263 },
>             { id: 9027, psc: 264 },
>             { id: 36996, psc: 263 },
>             { id: 36997, psc: 264 }
>         ]
>     },
>     lte: {
>         lac: 5121,
>         enb: 902,
>         cells: [
>             { id: 1 },
>             { id: 2 }
>         ]
>     }
> }
>
> Jogos kérdés lehet, hogy miért nem írtam az gsm és lte cellákat az alábbi 
> egyszerűbb formában, numerikus tömbként:
>
> gsm: {
>     cells: [9021, 9022]
> }
>
> lte: {
>     cells: [1, 2]
> }
>
> Azért nem írtam így, mert a celláknak nem csak egyetlen tulajdonságuk van 
> (azonosító), hanem például a psc is (umts hálózatokban). Így ahány umts 
> cella van, annyi psc is.
>
> Megjegyzések: Igazából az rnc is a cella tulajdonsága, de ez egy adott 
> helyszínen mindig állandó, ezért nem írjuk ki cellánként, hanem a 
> bázisállomás tulajdonságaként tekintjük. Mérünk még számos más értéket is a 
> cellákra, amelyeket egyelőre csak elvétve tüntettünk fel az OpenStreetMap 
> adatbázisában: bcch, bsic, ulch, dlch, valamint a példádban is említett 
> direction.
>
> Írhattam volna az alábbi formában, a cellák számával megegyező elemszámú 
> tömbként a psc-t is JSON formátumban, de ez nem adja vissza jól a 
> struktúrát:
>
> umts: {
>     cells: [9021, 9022, 9026, 9027, 36996, 36997]
>     psc: [263, 264, 263, 264, 263, 264]
> }
>
> Az OpenStreetMap kulcs=érték párosokban gondolkodó címkézési rendszerében 
> mégis az utóbbi formát választottuk, mert még mindig jobban olvasható, 
> mintha a struktúrát gyönyörűen visszaadó JSON valamilyen escape-elt vagy 
> base64-kódolt változatát tennénk oda.
>
> Nemcsak emberi, hanem gépi értelmezésre is alkalmas a választott formátum. 
> A szerkesztésre használt API overpass lekérdezéssel olvassa az OSM adatokat 
> és szétszedi a fenti normalizált alakra, hogy aztán automatikusan 
> kiegészíthesse az újabb mérésekből érkezett rokon cellákkal, majd 
> visszaalakítja kulcs-érték párokká.
>
> Elsőre bizonyára nehezen értelmezhető, különösen a több szolgáltatós 
> tornyok és a részben felmért adatokat tükröző fixme-k miatt. Remélem, hogy 
> a példa alapján tisztább lett a kép.
>
> Üdv:
> András
>
> 2015. november 4., szerda 22:14:22 UTC+1 időpontban kdano a következőt 
> írta:
>>
>> Gyorskérdés az adatbázissal kapcsolatban (nem mélyedtem el nagyon abban, 
>> hogy pontosan mit is jelent az a rengeteg tag, amit ilyen tornyokra 
>> címkéztek):
>> Az normális, hogy ugyanaz az érték pontosvesszővel elválasztva többször 
>> is szerepel?
>> pl.
>> "lte:cellid=1;2;3; 1;2;3; 0;1;2;11"
>> "umts:PSC=48;44;222;46;47;48;44;45;46"
>> "gsm:direction=70;180;180; fixme"
>> "gsm:LAC=110; 110"
>>
>> mert én csak annyit értek ebből, hogy az osmose hülyét kap tőle :)
>>
>> kdano
>>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20151105/3166f1c1/attachment.htm>