Sziasztok!
Segítséget szeretnék kérni a tanult közösségtől az alábbi problémában.
Adottak sorokban adatok, pl.:
Kő Pál 8237 TIHANY, Hegy utca 8
Noname Frigye 8230 BALATONFÜRED, VIrág sor 15 C. lph. 4. em. 13. a.
stb.
Ebből szeretném pl. pontosvesszővel elválasztani a különböző részeket, amik:
név, IRSZ, Telepules, Kozterulet_Neve, Kozterulet_Tipusa, Hazszam1, Hazszam2, hazszam_Betujele, lepcsohaz, Emelet, Ajto, Ajto_Betujele
Nincs minden érték minden sorban, ott üres ;; kellene.
A közterület típusát a posta adataiból kellene megállapítani.
Mindezt powershellben, mivel windowsos környezetben dolgozunk, és az IT nem enged fejleszteni, viszont ez a kis script nagyban megkönnyítené 30-40 ember munkáját.
Ameddig eljutottam:
'Kő Pál 8237 TIHANY, Hegy utca 8' -replace '(\D+)(\s)(\d+)(\s)(\w*), (.*)', '$1;$3;$5;$6'
Eddig aránylag egyszerű volt, a település név után jön ugye a szépség, az utcanév addig tart, amíg a köztertípus listából nem talál egyezést, és az ...
Ha valaki segítene, megköszönném, Attila
- 157 megtekintés
Hozzászólások
Csak bonyolítani szeretnék...
Az én lakcímem (kormányablak, lakcímkártya) ilyen alakú:
IRSZ VÁROS kerület utcanév típus házszám.
A ép. D lph. FSZ. 1 a.
(ahol pont van a kártyán, oda raktam én is)
Ezt a címet sok szolgáltató nem tudja kezelni, ezt-azt kihagynak belőle.
"Normális ember már nem kommentel sehol." (c) Poli
- A hozzászóláshoz be kell jelentkezni
És ez egy a sok szépség közül. Mert ott lesz az az eset is, amikor ki sincs írva a közterület típusa (Budapest, Rákóczi 25), akkor az épület, lépcsőház, emelet, ajtó infókat is tudják annyiféleképp leírni, ahány lakás csak létezik egyáltalán....
- A hozzászóláshoz be kell jelentkezni
Honnan jönnek az adatok? Van ráhatásod?
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Nincsen ráhatásom. De az adatszerkezet fix, egy sorban, ebben a sorrendben, a címtípus után nem minden adat szerepel.
- A hozzászóláshoz be kell jelentkezni
Induljunk ki abból, hogy az általam vázolt felállás a közterület típusig fixen megvan. Amit nem tudtam megoldani, hogy listából ellenőrizzek powershellben, valamint a feltételek kezelése hogyan illeszthető a ps regex pároshoz.
- A hozzászóláshoz be kell jelentkezni
Az nem megoldás, - amit sokan csinálnak - hogy ország, irányítószam, város, közterület neve, közterület típusa, házszám, "cím minden más része"
A "cím minden más része"-be tesznek bele, minden mást, ami a házszám után van. Sztem. egy ilyen adathalmaznál millió egy variáció és rövidítés van sajnos. Ha sok a szabadidőd, akkor elkezdheted feltanítani a kódot majd ezen kombinációkra. Egy dolgot nem lehet kivédeni, az pedig a különböző elgépelési hibák.
Sajnos itt az ellenőrzött és kontrollált bevitel lenne a jó irány. Felvetni, mint fejlesztési pont a szoftver oldalán, majd a régi címeket kovertáltatni a program használóival.
Tőlünk nyugatabbra egyszerűen minden el van választva egy per jellel, az emelet pedig az ajtószámba van kódolva.
10 - 10-es házszám (tipikusan kertes ház)
10/1 -10-es házszám, 1-es ajtó vagy 10/A megfelelője Magyarországon.
10/201 -10-es házszám, 201-es ajtó (második emelet, mert az ajtó száma nagyobb, mint 200)
10/3/201 -10-es házszám, harmadik lépcsőház, 201-es ajtó.
Lehetne Magyarországon valahogy így is egyszerűsíteni a címeket. Akkor nem kéne ennyit szívni ezzel.
- A hozzászóláshoz be kell jelentkezni
Nem lehet az adatszerkezeten módosítani, nem járható.
A kimenet postázóba megy, a posta pedig tagolva kéri (csak mi máshonnét egyben kapjuk).
- A hozzászóláshoz be kell jelentkezni
Akkor ahonnan jönnek az adatok ott lenne érdemes feldobni a dolgot, ha ez hosszú távon probléma. Nyilván hivatkozva, hogy a posta csak így veszi át, ezért lesznek szívesek ennek megfelelő outputot átadni.
A kézi hajtányos megoldásokkal az a baj, hogy aki csinálta annak kell felkészítenie mindenre is. Hosszú távon ez pedig szívás annak, aki ezt bevállalja. Ha netán elválnak útjaik a munkáltatóval, akkor megint az lesz, hogy senki sem fogja felvállalni a karbantartását a scriptnek és visszatérnek az előző problémához, a script meg megy a levesbe.
Tehát hosszú távon érdemesebb az az út, hogy eleve megfelelő formában érkezzenek a címek. Ezt mondja sok év tapasztalat.
- A hozzászóláshoz be kell jelentkezni
Szerintem a postat csak az iranyitoszam erdekli, hiszen az hatarozza meg a cel fiokot. Ha meg mar oda elert a csomag, onnantul ugyis ember kezbesiti.
Szoval lehet hogy meg kellene oket kerdezni, siman lehet hogy az iranyitoszam utani maradek stringet betoljatok egy mezobe es kesz.
- A hozzászóláshoz be kell jelentkezni
^(?<name>\V+)\b\h+\b(?:\w?\-?)?(?<zipcode>\d{4})\b\s+(?<city>\V+)\h*\b\,\h+(?<street>\V+)\b\h+(?i:(?<type>utca|sor|köz|körút|egeszitsd_ki_a_listat))\h+(?<housenumber>\d+)\h*(?<housechar>\w+)?\b(?<in_house>\N+)?$
Named capture grouppal, igy ps-el mar kulon valtozokba kapod meg a match-ben az adatokat name, zipcode..., kozteruletjellegeket egeszitsd ki.
Zipcodebol elfogadja a H- kezdeteut is de csak a szamot mentti.
Ez szandekossan nem fogadja el azokat a sorokat amikben sorteres van, ha a veletlen entereket is kezelni akarod akkor a \V \N helyett . (es multiline flag), a \h helyett meg \s
A hazon beluli azonositot (in_house ) kulon dolgoznam fel, gyorsabb es egyszerubb is illetve mivel ott barmi lehet teljesen strukturalaltanul, arra nem idealis a regexp.
- A hozzászóláshoz be kell jelentkezni
Es ha el van gepelve az "utca"? Nem fog illeszkedni a regexp es buko. Ezeket mindig nagyon flexibilisen kell kezelni, hiszen semmi se garantalt.
- A hozzászóláshoz be kell jelentkezni
Biztos hogy csak magyar cimeket kaptok? Az a baj az ilyen parse-olassal, hogy bejon egy mas formatumu iranyitoszam es borul az egesz.
Es ha vmi udulo cimerol van szo, ahol HRSZ-bol all a cim?
- A hozzászóláshoz be kell jelentkezni