Aby som bol presny ten lokalizacny udaj by mohol byt sucastou
/v2/subjekty/{subjektId}
@Tamas_Szoke co takto daco taketo:
{
“createdAt”: “2014-07-14T03:54:45.913095Z”,
“dic”: “1075332797”,
“gpsLat”: 48.11087,
“gpsLon”: 17.111543,
“href”: “/v2/subjekty/1”,
“ico”: “00151564”,
“id”: 1,
“nazov”: “Prva pokusna s.r.o.”,
“obec”: “Bratislava - mestská časť Petržalka”,
“psc”: “85104”,
“stat”: “Slovensko”,
“ulica”: “Mamateyova”,
“ulicaCislo”: “10”,
“updatedAt”: “2017-06-13T09:39:36.963Z”
}
Cize je tam aj adresa a rovno aj GPS suradnice obce subjektu
1 Like
…vymyslime…doplnime info do API o adrese subjektu, ale ta adresa nemusi byt 100% presna…adresu mozu pouzivatelia ITMS2014+ modifikovat pre potreby domeny, ktora sa v ITMS2014+ riesi…ale urcite lepsie ako nic 
…koncepnejsie by bolo, keby v ramci RPO popremyslali nad takymito vecami…nech daju verejne API, kde si mozete potahat pravnicke osoby aj s adresnymi udajmi napr. s kodmi NUTS, gps suradnicami
…napr. za miesto realizacie projektu nemame problem zverejnovat jednotlive urovne NUTS aj s kodmi podla ciselnika NUTS…
Tak a je to uz aj live, napr.
https://opendata.itms2014.sk/v2/subjekty/1
https://opendata.itms2014.sk/v2/dodavatelia/111
3 Likes
tak uz to je v PROD…tomuto hovorim agilita
super, ak budu suradnice tak je to este jednoduchsie. Niektore BI nastroje vedia pracovat priamo s lat/lon a da sa to jednoducho vizualizovat bez potreby dalsieho spracovania.
wow, to bolo rychle… nikto mi nebude verit ked to poviem na pive 
2 Likes
Silne pochybujem, ze tam chalani maju uz integrovany reg. adries.
Tie GPS suradnice su ako pisem vyssie k OBCI subjektu/dodavatela. Mame to z geocoding-u z googla… Ale aspon daco.
1 Like
…mame, ale pouzivame ju iba na identifikaciu PSC…
pre nas case:
- evidovanie subjektov,
- evidovanie osob,
ani nejak register adries nepotrebujeme, nakolko RPO a RFO nam posle adresu subjektu/fyzickej osoby
a ako som pisal vyssie…adresa subjektu a osoby v ITMS2014+ moze byt predmetom zmeny…napr. pri zamestnancovi subjektu nedrzime jeho sukromnu adresu, ale vacsinou si ju zmenia na adresu subjektu, pre ktory dana osoba pracuje
1 Like
je to super aj takto, lebo nemusim vyrabat bod na mape sam. Pri parovani cez register PSC (obce a ulice) som mal vela blank fieldov s lat/log datami z ITMS to bude jednoznacne. Uz ked mame bod tak naparovat to na nejaky polygon je easy (NUTS 5,4,3).
Ma este jednu otazku. Dal by sa
get /v2/zonfp/prijate/{id} - “popisProjektu”: zverejnovat bez HTML tagov?
Vieme to stripnut, ale bude to gulas. Useri do popisu pastuju kadeco, tabulky, formatovany text, co ta napadne to tam daju. Ak stripneme html tak z tabulky nic nezostane. Odporucam to robit client side podla konkretnej potreby.
1 Like
nerozumiem otazke…co znamena, ze kolisu…voci comu kolisu…voci akemu cislu OPTP kleslo o 4%?
ID projektu (zvyraznil som nizsie v priklade) je len jedno a je jasne identifkovane v ramci API, napr. tu https://opendata.itms2014.sk/v2/projekty/vrealizacii
priklad:
{
“cisloZmluvy”: “Z312020A017”,
“createdAt”: “2015-10-29T09:57:18.114Z”,
“datumPlatnostiZmluvy”: “2015-11-05T00:00:00Z”,
“datumUcinnostiZmluvy”: “2015-11-06T00:00:00Z”,
“href”: “/v2/projekty/vrealizacii/1”,
“id”: 1,
“kod”: “312021A017”,
projekt ma aj jedinecny kod (zvyraznil som vyssie v priklade), ktory v sebe nesie informaciu o tom do akeho OP a pod ktoru pirioritnu os projekt patri
na subjekt je spraveny href, ktory obsahuje ID subjektu…cize treba si potom subjekt dohladat v endpointe subjekty https://opendata.itms2014.sk/swagger/?url=/v2/swagger.json#!/subjekt/subjekt_show
v detaile projektu napr. projekt ID = 1 https://opendata.itms2014.sk/v2/projekty/vrealizacii/1 je href na OP, na vyzvu a na ZoNFP
info o OP, vyzve je v detaile ZoNFP a su identifikovane cez href
subjekt je identifkovany opat cez href a ID
ID vyzvy je jedinecne ako vsetky ID
ok, rozumiem.
Spravil som z dat report, ktory pocita priemernu dlzku procesu, schvalovania, kontrahovania, predlozenia 1.ZoP a preplatenia prvej ZoP. Vsimol som si ale par nezrovnalosti v datumoch. Napr:
- niektore ZoNFP v list prijataZonfp maju nizsi datumPredlozenia ako createdAT (napr. id 229, 1430, 2187, 2209, 1434), celkom pri 46 zaznamoch je createdAT>datumPredlozenia - boli predlozene skor nez ako boli vytvorene
- pri 14 projektoch v realizacii je datumUcinnostiZmluvy<datumSchvalenia - boli zazmluvnene skor nez ako boli schvalene
Kedze tieto ZoNFP a Projekty kazia vypocty - vylepsuju casy tak ich neberiem do uvahy ale niekde asi bude chyba.
3 Likes
cauko,
uvadzam priklad pre ID 1430, aby sme sa bavili o tom istom:
“createdAt”: “2016-07-12T22:26:27.022Z”,
“datumPredlozenia”: “2016-07-12T00:00:00Z”
Myslel si pre toto ID tieto datumy?
- createdAt je datoveho typu timestamp, teda datum aj s casovym udajom
- datumPredlozenia je datoveho typu date, teda datum bez casoveho udaju
Kedze domenovo nas pri datume predlozenia nezaujima cas, javi sa to potom casovo skorsie ako samotne vytvorenie, pri odoslani vsak treba vsak prihliadat len na datum.
Miso ma predbehol…cakal som na potvrdenie tych atributov.
Cize ked niekto vytvoril a odoslal ZoNFP v ten isty den, tak vznikne tento nesulad. Cize dopad na statistiky by nemal byt az taky vyrazny
Alebo si identifikoval aj iny typ nesuladu?
Cau,
pozrel som si to este raz, nasiel som chybu u seba. Pri pri zmene createdAt na type date/time mi powerquery spravil napr. pri id1430 z 2016-07-12T22:26:27.022Z toto 2016-07-13T00:26:27.0220000 ak to zmenim na date/time/timezone tak je to spravne. (2016-07-12T22:26:27.0220000+00:00). Stale som ale nasiel 23 zaznamov pri ktorych je stale createdAt>datumPredlozenia vid subor data_dtschvalenia.xlsx (10.6 KB)
Podavanie projektov je proces na strane ziadatela, takze tu tych par zaznamov naozaj nekazi statistiku. Podstatnejsie je to pri podpose zmluvy, kde pri vestkych financnych nastrojoch (zameranieProjektu) je datum ucinnosti zmluvy nizsi ako datum schvalenia - ale tieto zaznamy som odfiltroval. Casy potom vyzeraju takto:
2 Likes