Re: [osm-hu] Re: ref vagy ref:cég vagy ref:cég:hu vagy ref:hu:cég vagy ref:cég:HU vagy ref:HU:cég

[bkil]

Még mindig az adószámról beszélünk amúgy? Nekem annyira nem szívügyem, csak
azt hittem ez egy példa volt amin keresztül szerettél volna valami
bonyolultabbat kérdezni.

On Mon, Dec 17, 2018 at 5:55 PM Imre Samu <pella.samu at gmail.com> wrote:

> >érdemes elolvasni a wiki oldalaikat: a ref:vatin:hu-ból nem
> származtatható a ref:vatin és fordítva sem mindig igaz.
> >Az előbbi azért, mert nem kötelező EU közösségi adószámot igényelni, a
> másik irány pedig mert nem tudod az adónemet,
> >bár az operator:addr-ban tényleg benne lehet a székhely ha feltüntette
> valaki, de ha csak az hiányzik az is plusz számolás.
>
> Én egy jó kompromisszumnak tartanám az EU-s adószámot  - legalábbis az egy
> elég  fix ID ( első 8 számjegy )  -  a székhely és az Áfakör változhat.
> A Magyarországon kiadott közösségi adószámok az országot azonosító ”HU”
> kódból, valamint a belföldi adószám első 8 számjegyéből állnak, a
> következőképpen: „HUxxxxxxxx.”.""
>
> de ha maximalisták akarunk lenni, akkor meghajlok  :)
>

Eredetileg én sem ragaszkodtam hozzá, de Kesztölcön felnyitották a
szememet, hogy eddig álomvilágban éltem és meggyőztek a fenti érveléssel.
Én is tévedhetek.

Ez nem feltétlenül maximalizmus kérdése, hanem egyszerűen nem lehet
származtatni a kettőt egymásból, így nem redundánsak. A kettő közül a
magyar adószámot triviális verifikálni: rá kell nézni a
nyugtára/honlapra/cégtáblára/árlistára/stb. Az EU adószám ellenőrzéshez már
kicsit izzadságszagú, ahhoz meg kell látogatni egy külsős oldalt és kézzel
bepötyögni az adatokat, bár néha ez is fent van a hivatalos portálon
(vicces esetben teljesen másik oldalán).

Viszont  kellene egy adószám monitorozó rendszer, ami
> -  kihajigálja az elavult / megváltozott adószámokat.  ( NAV publikus api
> ? )
>

Esetleg a hivatalos weboldalról, cégközlönyből vagy az önkormányzati
nyilvántartásból is lehet parszolni, bár utóbbi nem mindenhol frissül.

De előny, hogy adószám elavulás alapján tud következtetni egy POI
életcilkus változásaira is: ha mondjuk felszámolás alá került a cég, akkor
már FIXME, hogy él-e még a söröző.

Ezt minden esetre írjuk fel az OSM web crawler wishlistjére:
* ref:vatin*
* addr:*
* contact:*
* opening_hours
* start_date
* sport

Kisebb nehézség, hogy a valóságban sokszor úgy szűnnek meg sörözők, hogy
újranyílik a helyükön a másik, és emiatt lecserélődik minden: adószám,
honlap, néha a név és wifi is.

-  ahol az EU adószám és amagyar adószám első 8 karaktere nem egyezik meg.
>  ( ez a könnyebbik rész )
>

Akár meg is próbálhatná kijavítani: lookup egyik, utána lookup másik és
melyik a frissebb, melyik passzol jobban a POI tulajdonságaihoz.

Te milyen elenörzéseket végeznél még el ?
>

Ha hiányzik az egyik, a másikból felviheti amennyiben létezik. Erre érdemes
a botnak cache-et is fenntartania. Bár nem biztos, hogy ez a csek
API-zható, mintha CAPTCHA-t kért volna ahol néztem.

Illetve mindkettőnek ellenőrizhetnénk a szintaxisát is - a ref:vatin:hu az
utolsó számjegyei szempontjából is behatárolt.

Én végigjárnám a changset-eket is emellé és amennyiben a ref:vatin* régebbi
mint az utolsó módosítása néhány kulcs mezőnek, mint az
operator*/brand/internet_acces:ssid, akkor szintén bejeleznék. Ha az
utóbbiakat később adták hozzá, akkor csak közepesen gyanús a pont.

Továbbá adatbázis szinten korrelálnám az operator* és ref:vatin* együttes
előfordulásait, és az outlier-eket szintén be lehetne jelezni, a hiányzókat
pedig fel lehetne ajánlani kitöltésre.

Valószínüleg a licensz megjegyzésem  a Wikidata-ból történő OSM importra
> vonatkozott
>

Igen, arra utaltam.

De bárki  ( mint 3rd party )   bármikor összefésülheti a Wikidata+OSM
> adatokat és egy weboldalon megjelenítheti.
>

Ez eddig rendben van.

  Csak az osm szeretne fehérebnél is fehérebb lenni.
> ( Ráadásul a Wikidata-ba mindenféle dolgokat beimportálnak ;   viszont az
> USA  és az EU egész máskép értelemzi az adatbázis jogot :
> https://en.wikipedia.org/wiki/Sui_generis_database_right
>  A probléma ha jól értem, hogy hiába CC0-a a wikidata , az ide bekerülő
> rengeteg ( beimportált ) adata licensze nem CC0-a, vagy public domain )
> )
>

Nos pont ez az, hogy amit én felmérek nektek, odaadom teljesen tisztán. De
ha onnan átlapátoljuk a wikidata-ba, utána ha meggondoljuk magunkat, már
csak bottal lehet piszkálni ha vissza kellene hozni, főleg ha a
wikidata-ban valaki hozzányúlt közben.

Aztán van itt még egy meghökkentő probléma amire nem is gondoltam eddig. Az
idő múlásával megváltozhat a wikidata hozzárendelés, ezáltal a felmérés
idejéhez képest teljesen új jelentést kapcsolva a ponthoz. Ennek során el
is veszhet emiatt információ. Viszont ami a ponton van, az legalább mindig
együtt marad. Egy friss példa:

https://wiki.openstreetmap.org/w/index.php?title=Key:name&diff=next&oldid=1638798

Ez ritka vagy lehetetlen eseménynek hangzik, de így átgondolva a kulcsok
evolúciója egy bizonyos számú kiterjesztés után gyakran elér egy szintet,
amikor újabb jellemzők hozzáadása már nem lehetséges konfliktusok nélkül,
és ilyenkor gyakorlatilag "forkolódik" a fogalom két, specializáltabb
jelentésre ahol már megadhatók a korábban konfliktáló jellemzők is.

Máskor egyszerűen nem létezik még a felméréskor az adott tökéletesen
specifikus wikidata fogalom, viszont egy tágabb jelentésben vagy egy "for
all intents & purposes" ekvivalens jelentésre már létezik, így azt linkelik
be. Ezután az évek alatt megszületik a specifikusabb fogalom is és nem
minden jellemző migrálódik vagy migrálható át a kettő között. Vegyük észre,
hogy a wikidata ID nem feltétlenül stabil UUID abban az értelemben ahogy mi
szeretnénk.

de mindenesetre - ez egy részlettéma.
> Ha ragaszkodsz a pluszmezőkhöz, akkor meghajlok.   ( viszont az
> életciklusuk monitorozására ( megszünt/változott) kellene valamit
> kitalálni, mert később beterit bennünket a sok változás.
>

Igen, ez mindenképpen jogos előrelátás. Bár a fenti monitorozó ötletek amit
sorolsz elég jól lefedik. Esetleg még szerkesztő/KeepRight validátort
lehetne írni ami csipog mentés előtt ha eltér a kettő.

Ugyanúgy léteznek URL validátorok is, viszont ezt sem futtatják/nézik
sokan, így tele van broken linkkel az OSM. Valamit lépni kellene abba az
irányba, hogy az emberek szeressék QA-zni az OSM-et, illetve menjenek
survey-re olyan pontokhoz ami survey_date (vagy mtime + source=survey)
alapján mondjuk több mint egy éves. Lehetne valami mapping party szervező
toolt írni ami ezt is figyelembe veszi.

Apropó, a többi élő contact:* crawling alapján a telefonszámot is lehetne
frissíteni, bár ahhoz, hogy ez tökéletesen működjön, szükség volna belső
állapotra szintén külső DB-ben (hogy melyik telefonszám melyik weboldalról
származik, ha onnan).
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20181220/2824c909/attachment.htm>