OpenCellID

2015. Nov. 5., Cs, 12:28:21 UTC

Szia!

Amikor az elválasztójelről döntöttem, nem gondoltam végig a halmaz és a 
lista megkülönböztetését. Nem egyértelmű, hogy az OSM-ben a pontosvesszővel 
elválasztott értékek halmazt vagy listát jelentenek-e. Találtam egy írást, 
amelyben éppen azt ismeri fel a szerző, hogy nem tekintheti halmaznak, 
hiszen vannak esetek, amikor ismétlődhetnek az értékek és fontos a 
sorrendjük is:

Semicolons in OSM Tags
http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html

A Balatonon is van ilyen hajózási jel:
seamark:beacon_isolated_danger:colour=black;red;black

A fentiek alapján szerintem használhatjuk a pontosvesszőt sorbarendezett 
lista elemeinek elválasztására. A cellák elválasztására szolgáló 
pontosvessző nem is volt számunkra kérdés. Sokat töprengtem viszont egyes 
szolgáltatók elválasztásán, felmerült többféle elválasztójel, talán még a 
"|" karakter is.

Végül a "; " jelet választottuk, mert így értelmezhető egyaránt 
pontosvesszős listaként és a szóköz figyelembevételével kétszintű 
elválasztásként is. Volt már gondunk a "; " jelből, ugyanis ha egy ilyet iD 
editorban szerkesztenek, kimazsolázza az összes szóközt a pontosvesszők 
mögül. Szerencsére egyedi volt az eset, de mindenképpen figyelemfelhívó. Ha 
át kell állnunk másra, a "|" elválasztást fogom javasolni.

A "; " jel az egy helyen szereplő szolgáltatókat választja el, tehát ha 
kicseréljük "|"-re, akkor így fognak kinézni az általad felvetett példák:

# három szolgáltató egyenként 3-4 cellával
lte:cellid=1;2;3|1;2;3|0;1;2;11

# egy szolgáltató sok cellával
umts:PSC=263;264;263;264;263;264
umts:cellid=9021;9022;9026;9027;36996;36997

Fontos tehát, hogy két lista van egymásba ágyazva, egyik sem halmaz. A 
sorrend azért fontos, mert több kulcsban azonos pozícióban levő elemek 
összetartoznak (pl: umts:PSC és umts:cellid), az adatok pedig 
ismétlődhetnek. Remek példa erre az lte:cellid címkében kétszer megjelenő 
1;2;3.

Üdv:
András

2015. november 5., csütörtök 10:14:26 UTC+1 időpontban kdano a következőt 
írta:
>
> 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/fa7345f4/attachment.htm>