« zpět na výpis měsíce |

[Talk-cz] problém s gml řetězcem

Vlákno 15.7.2012 - 28.1.2013, počet zpráv: 13


15.7.2012 11:18:40 (#1)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
ahoj, netušíte někdo, co je za problém s tímhle gml řetězcem při převodu postgis funkcí st_geomfromgml? ruian-test=# insert into test values (st_geomfromgml('<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2" gml:id="HPA.13631950010" srsName="urn:ogc:def:crs:EPSG::2065" srsDimension="2"><gml:exterior><gml:Ring><gml:curveMember><gml:LineString gml:id="HPA.13631950010.1"><gml:posList>481595.25 1102177.50 481594.26 1102173.81 481595.20 1102173.14 481595.73 1102172.20 481595.87 1102171.13 481599.33 1102170.22 481599.01 1102169.00 481606.76 1102166.97 481605.22 1102161.03 481600.78 1102162.15 481599.03 1102154.97 481591.89 1102156.87 481589.28 1102157.56 481590.24 1102161.70 481590.97 1102164.88 481589.46 1102165.28</gml:posList></gml:LineString></gml:curveMember><gml:curveMember><gml:Curve gml:id="HPA.13631950010.2.3"><gml:segments><gml:ArcString><gml:posList>481589.46 1102165.28 481588.41 1102165.67 481587.72 1102166.19 481587.07 1102166.85 481586.30 1102168.29 481585.96 1102169.71 481586.03 1102171.13</gml:posList></gml:ArcString></gml:segments></gml:Curve></gml:curveMember><gml:curveMember><gml:LineString gml:id="HPA.13631950010.3"><gml:posList>481586.03 1102171.13 481588.39 1102179.94 481588.85 1102179.86 481590.37 1102185.72 481594.17 1102184.79 481594.52 1102186.07</gml:posList></gml:LineString></gml:curveMember><gml:curveMember><gml:Curve gml:id="HPA.13631950010.4.5"><gml:segments><gml:ArcString><gml:posList>481594.52 1102186.07 481595.95 1102185.59 481597.56 1102183.98 481598.13 1102181.79 481597.87 1102180.21</gml:posList></gml:ArcString></gml:segments></gml:Curve></gml:curveMember><gml:curveMember><gml:LineString gml:id="HPA.13631950010.5"><gml:posList>481597.87 1102180.21 481596.54 1102180.56 481595.68 1102177.39 481595.25 1102177.50</gml:posList></gml:LineString></gml:curveMember></gml:Ring></gml:exterior></gml:Polygon>')); ERROR: invalid GML representation KONTEXT: SQL function "st_geomfromgml" statement 1 ten xml string se zdá být validní. háže mi to postgresql 9.2 beta2 + postgis 2.0.1. na jiné verzi jsem to nezkoušel. v postgresql logu je to samé co mi to píše v pgsql, není tam žádné doplňující info. je to při importu souboru 20120630_OB_500291_UKSH.xml.gz. ff ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120715/925a0aea/attachment.bin>

15.7.2012 11:44:16 (#2)
gravatar

hanoj

<ehanoj at gmail.com>
717
Nemuze to souviset s timto? http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998&MENUID=10769&AKCE=DOC:10-VDP_NOVINKY Ve výměnném formátu VFR je chybně ukládána geometrie parcel a stavebních objektů, které jsou tvořeny kružnicí (případně se kružnice vyskytuje jako jeden z vnitřních polygonů parcely). Problém se vyskytuje v souborech rrrrmmdd_OB_cccccc_UKSH.xml. Ve výměnném formátu VFR je chybně ukládána geometrie parcel, které obsahují vnitřní polygon, který je tvořen částí oblouku. Problém se vyskytuje v souborech rrrrmmdd_OB_cccccc_UKSH.xml. PS: jak resis, ze jsou souradnice kladne a maji byt zaporne? ha hanoj Dne 15. července 2012 23:18 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): zobrazit citaci
> ahoj, > > netušíte někdo, co je za problém s tímhle gml řetězcem při převodu > postgis funkcí st_geomfromgml? > > ruian-test=# insert into test values (st_geomfromgml('<gml:Polygon > xmlns:gml="http://www.opengis.net/gml/3.2" gml:id="HPA.13631950010" > srsName="urn:ogc:def:crs:EPSG::2065" > srsDimension="2"><gml:exterior><gml:Ring><gml:curveMember><gml:LineString gml:id="HPA.13631950010.1"><gml:posList>481595.25 > 1102177.50 481594.26 1102173.81 481595.20 1102173.14 481595.73 > 1102172.20 481595.87 1102171.13 481599.33 1102170.22 481599.01 > 1102169.00 481606.76 1102166.97 481605.22 1102161.03 481600.78 > 1102162.15 481599.03 1102154.97 481591.89 1102156.87 481589.28 > 1102157.56 481590.24 1102161.70 481590.97 1102164.88 481589.46 > 1102165.28</gml:posList></gml:LineString></gml:curveMember><gml:curveMember><gml:Curve > gml:id="HPA.13631950010.2.3"><gml:segments><gml:ArcString><gml:posList>481589.46 > 1102165.28 481588.41 1102165.67 481587.72 1102166.19 481587.07 > 1102166.85 481586.30 1102168.29 481585.96 1102169.71 481586.03 > 1102171.13</gml:posList></gml:ArcString></gml:segments></gml:Curve></gml:curveMember><gml:curveMember><gml:LineString > gml:id="HPA.13631950010.3"><gml:posList>481586.03 1102171.13 481588.39 > 1102179.94 481588.85 1102179.86 481590.37 1102185.72 481594.17 > 1102184.79 481594.52 > 1102186.07</gml:posList></gml:LineString></gml:curveMember><gml:curveMember><gml:Curve > gml:id="HPA.13631950010.4.5"><gml:segments><gml:ArcString><gml:posList>481594.52 > 1102186.07 481595.95 1102185.59 481597.56 1102183.98 481598.13 > 1102181.79 481597.87 > 1102180.21</gml:posList></gml:ArcString></gml:segments></gml:Curve></gml:curveMember><gml:curveMember><gml:LineString > gml:id="HPA.13631950010.5"><gml:posList>481597.87 1102180.21 481596.54 > 1102180.56 481595.68 1102177.39 481595.25 > 1102177.50</gml:posList></gml:LineString></gml:curveMember></gml:Ring></gml:exterior></gml:Polygon>')); > ERROR: invalid GML representation > KONTEXT: SQL function "st_geomfromgml" statement 1 > > ten xml string se zdá být validní. háže mi to postgresql 9.2 beta2 + > postgis 2.0.1. na jiné verzi jsem to nezkoušel. v postgresql logu je to > samé co mi to píše v pgsql, není tam žádné doplňující info. je to při > importu souboru 20120630_OB_500291_UKSH.xml.gz.

16.7.2012 11:47:48 (#3)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 15.7.2012 23:44, hanoj napsal(a): zobrazit citaci
> Nemuze to souviset s timto? > http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998&MENUID=10769&AKCE=DOC:10-VDP_NOVINKY > > Ve výměnném formátu VFR je chybně ukládána geometrie parcel a > stavebních objektů, které jsou tvořeny kružnicí (případně se kružnice > vyskytuje jako jeden z vnitřních polygonů parcely). Problém se > vyskytuje v souborech rrrrmmdd_OB_cccccc_UKSH.xml. > > Ve výměnném formátu VFR je chybně ukládána geometrie parcel, které > obsahují vnitřní polygon, který je tvořen částí oblouku. Problém se > vyskytuje v souborech rrrrmmdd_OB_cccccc_UKSH.xml.
to bude asi ono. akorát mi není jasné, jestli lze z toho řetězce vytvořit správný řetězec jeho přepsáním, nebo je chyba jiného rázu a opravit ji nelze, protože v něm některá data chybí. hledal jsem na netu gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v nějakém aktualizačním souboru správně a při updatu se to přepíše? zobrazit citaci
> PS: jak resis, ze jsou souradnice kladne a maji byt zaporne?
to zatím neřeším, netušil jsem, že to co je v datech není správně, a nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus nebo to vyžaduje ještě něco dalšího? zobrazit citaci
> ha > hanoj
ff zobrazit citaci
> > Dne 15. července 2012 23:18 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> ahoj, >> >> netušíte někdo, co je za problém s tímhle gml řetězcem při převodu >> postgis funkcí st_geomfromgml? >> >> ruian-test=# insert into test values (st_geomfromgml('<gml:Polygon >> xmlns:gml="http://www.opengis.net/gml/3.2" gml:id="HPA.13631950010" >> srsName="urn:ogc:def:crs:EPSG::2065" >> srsDimension="2"><gml:exterior><gml:Ring><gml:curveMember><gml:LineString gml:id="HPA.13631950010.1"><gml:posList>481595.25 >> 1102177.50 481594.26 1102173.81 481595.20 1102173.14 481595.73 >> 1102172.20 481595.87 1102171.13 481599.33 1102170.22 481599.01 >> 1102169.00 481606.76 1102166.97 481605.22 1102161.03 481600.78 >> 1102162.15 481599.03 1102154.97 481591.89 1102156.87 481589.28 >> 1102157.56 481590.24 1102161.70 481590.97 1102164.88 481589.46 >> 1102165.28</gml:posList></gml:LineString></gml:curveMember><gml:curveMember><gml:Curve >> gml:id="HPA.13631950010.2.3"><gml:segments><gml:ArcString><gml:posList>481589.46 >> 1102165.28 481588.41 1102165.67 481587.72 1102166.19 481587.07 >> 1102166.85 481586.30 1102168.29 481585.96 1102169.71 481586.03 >> 1102171.13</gml:posList></gml:ArcString></gml:segments></gml:Curve></gml:curveMember><gml:curveMember><gml:LineString >> gml:id="HPA.13631950010.3"><gml:posList>481586.03 1102171.13 481588.39 >> 1102179.94 481588.85 1102179.86 481590.37 1102185.72 481594.17 >> 1102184.79 481594.52 >> 1102186.07</gml:posList></gml:LineString></gml:curveMember><gml:curveMember><gml:Curve >> gml:id="HPA.13631950010.4.5"><gml:segments><gml:ArcString><gml:posList>481594.52 >> 1102186.07 481595.95 1102185.59 481597.56 1102183.98 481598.13 >> 1102181.79 481597.87 >> 1102180.21</gml:posList></gml:ArcString></gml:segments></gml:Curve></gml:curveMember><gml:curveMember><gml:LineString >> gml:id="HPA.13631950010.5"><gml:posList>481597.87 1102180.21 481596.54 >> 1102180.56 481595.68 1102177.39 481595.25 >> 1102177.50</gml:posList></gml:LineString></gml:curveMember></gml:Ring></gml:exterior></gml:Polygon>')); >> ERROR: invalid GML representation >> KONTEXT: SQL function "st_geomfromgml" statement 1 >> >> ten xml string se zdá být validní. háže mi to postgresql 9.2 beta2 + >> postgis 2.0.1. na jiné verzi jsem to nezkoušel. v postgresql logu je to >> samé co mi to píše v pgsql, není tam žádné doplňující info. je to při >> importu souboru 20120630_OB_500291_UKSH.xml.gz. > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120716/be6c3b90/attachment.bin>

16.7.2012 11:29:18 (#4)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
> hledal jsem na netu > gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám > invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v > nějakém aktualizačním souboru správně a při updatu se to přepíše?
*** Myslim, ze to opravi v nejakem pristim mesicnim celkovem vydani, validovat to neumim. zobrazit citaci
>> PS: jak resis, ze jsou souradnice kladne a maji byt zaporne? > to zatím neřeším, netušil jsem, že to co je v datech není správně, a > nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus > nebo to vyžaduje ještě něco dalšího?
*** Ano, zda se ze jen zaporne znamenko. (Někdy byva třeba v jinych datech prohodit X za Y...) PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne zajimaji jen: * parcely zastavene ("druh pozemku kod"= myslim 13 ) * adresni body hanoj

16.7.2012 11:48:21 (#5)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 16.7.2012 23:29, hanoj napsal(a): zobrazit citaci
>> hledal jsem na netu >> gml validátor pro verzi 3, ale asi zatím nic neexistuje. nebo mám >> invalidní data prostě ignorovat s tím, že to bude (nebo už i je?) v >> nějakém aktualizačním souboru správně a při updatu se to přepíše? > *** Myslim, ze to opravi v nejakem pristim mesicnim celkovem vydani, > validovat to neumim.
já jsem to nakonec vyřešil tak, že jsem do aplikace přidal parametr --ingore-invalid-gml. při importu to s tímhle parametrem kontroluje každou gml definici, takže je to pomalejší, ale zase to na chybné gml definici nespadne. pokud st_geomfromgml definici odmítne, tak se záznam uloží, jako by tam žádná definice nebyla. taky právě počítám s tím, že v nějakém updatu se to pak přehraje. otázka ovšem je, jestli se změní i údaj "platné od" (podle něj filtruju, jestli se má záznam zaktualizovat nebo ne, starší platné od nepřepíše novější platné od). asi by to bylo lepší navázat na id transakce, ale nikde jsem k tomu id transakce neviděl popis, jestli jdou ty transakce vzestupně nebo jsou id náhodná. zobrazit citaci
>>> PS: jak resis, ze jsou souradnice kladne a maji byt zaporne? >> to zatím neřeším, netušil jsem, že to co je v datech není správně, a >> nějak mě to netrklo :-) stačí, když před všechny souřadnice dám mínus >> nebo to vyžaduje ještě něco dalšího? > *** Ano, zda se ze jen zaporne znamenko. (Někdy byva třeba v jinych > datech prohodit X za Y...)
ok, takhle jsem to udělal. zobrazit citaci
> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne > zajimaji jen: > * parcely zastavene ("druh pozemku kod"= myslim 13 ) > * adresni body
a budovy? zobrazit citaci
> hanoj
ff ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120716/feda8707/attachment.bin>

17.7.2012 12:06:25 (#6)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
>> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne >> zajimaji jen: >> * parcely zastavene ("druh pozemku kod"= myslim 13 ) >> * adresni body > a budovy?
*** budovy jsou... a) bud zastavene parcely (dnes delane tracerem v JOSM) b) nebo bod stavebniho objektu a s tim toho mnoho neudelame. Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho generovat neco jako landuse=residential. Vic mne nenapada. hanoj

17.7.2012 12:06:52 (#7)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 16.7.2012 23:48, Miroslav Šulc napsal(a): zobrazit citaci
> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne > zajimaji jen: > * parcely zastavene ("druh pozemku kod"= myslim 13 ) > * adresni body > a budovy?
resp. stavební objekty. jaký je rozdíl mezi stavebními objekty a parcelami? ty ulice by se daly aktuálně použít aspoň ke kontrole, jestli nám na mapě nechybí. zobrazit citaci
>> hanoj > ff
ff ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120717/b6912f0c/attachment.bin>

17.7.2012 11:01:52 (#8)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 17.7.2012 00:06, hanoj napsal(a): zobrazit citaci
>>> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne >>> zajimaji jen: >>> * parcely zastavene ("druh pozemku kod"= myslim 13 ) >>> * adresni body >> a budovy? > *** budovy jsou... > a) bud zastavene parcely (dnes delane tracerem v JOSM) > b) nebo bod stavebniho objektu a s tim toho mnoho neudelame. > Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho > generovat neco jako landuse=residential. Vic mne nenapada.
stavební objekty mají v datech i hranice, proto se na to ptám. zobrazit citaci
> hanoj
ff ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120717/a35da9a3/attachment.bin>

17.7.2012 09:40:27 (#9)
gravatar

hanoj

<ehanoj at gmail.com>
717
Dne 17. července 2012 11:01 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): zobrazit citaci
> Dne 17.7.2012 00:06, hanoj napsal(a): >>>> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne >>>> zajimaji jen: >>>> * parcely zastavene ("druh pozemku kod"= myslim 13 ) >>>> * adresni body >>> a budovy? >> *** budovy jsou... >> a) bud zastavene parcely (dnes delane tracerem v JOSM) >> b) nebo bod stavebniho objektu a s tim toho mnoho neudelame. >> Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho >> generovat neco jako landuse=residential. Vic mne nenapada. > stavební objekty mají v datech i hranice, proto se na to ptám.
*** kdyz koukam na obec s DKM http://vdp.cuzk.cz/vymenny_format/soucasna/20120630_OB_584029_UZSZ.xml.gz tak v /vf:VymennyFormat/vf:Data/vf:StavebniObjekty/vf:StavebniObjekt vidim <soi:Geometrie><soi:DefinicniBod><gml:Point ... rikam to spravne? hanoj

17.7.2012 10:10:33 (#10)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 17.7.2012 21:40, hanoj napsal(a): zobrazit citaci
> Dne 17. července 2012 11:01 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> Dne 17.7.2012 00:06, hanoj napsal(a): >>>>> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne >>>>> zajimaji jen: >>>>> * parcely zastavene ("druh pozemku kod"= myslim 13 ) >>>>> * adresni body >>>> a budovy? >>> *** budovy jsou... >>> a) bud zastavene parcely (dnes delane tracerem v JOSM) >>> b) nebo bod stavebniho objektu a s tim toho mnoho neudelame. >>> Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho >>> generovat neco jako landuse=residential. Vic mne nenapada. >> stavební objekty mají v datech i hranice, proto se na to ptám. > *** kdyz koukam na obec s DKM > http://vdp.cuzk.cz/vymenny_format/soucasna/20120630_OB_584029_UZSZ.xml.gz > > tak v > /vf:VymennyFormat/vf:Data/vf:StavebniObjekty/vf:StavebniObjekt > > vidim > <soi:Geometrie><soi:DefinicniBod><gml:Point ... > > rikam to spravne?
uzsz jsou jen základní data bez originálních hranic, obsahují jen definiční body. musíš v tom formuláři nastavit kompletní datovou sadu, pak se ti ve výběru z údajů zaškrtnou i originální hranice. tyhle soubory pak mají v názvu uksh a obsahují právě i ty hranice objektů. např se můžeš podívat do souboru 20120630_OB_500291_UKSH.xml.gz, tam jsou 100%ně. já se pomalu pustím do importu kompletní sady dat, takže pak budeme vědět, u čeho všeho jsou ty geometrie (např. jestli jsou někde i u ulic apod.). zobrazit citaci
> hanoj
ff ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120717/2b62871c/attachment.bin>

17.7.2012 10:38:15 (#11)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 17.7.2012 22:10, Miroslav Šulc napsal(a): zobrazit citaci
> Dne 17.7.2012 21:40, hanoj napsal(a): >> Dne 17. července 2012 11:01 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >>> Dne 17.7.2012 00:06, hanoj napsal(a): >>>>>> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas vlastne >>>>>> zajimaji jen: >>>>>> * parcely zastavene ("druh pozemku kod"= myslim 13 ) >>>>>> * adresni body >>>>> a budovy? >>>> *** budovy jsou... >>>> a) bud zastavene parcely (dnes delane tracerem v JOSM) >>>> b) nebo bod stavebniho objektu a s tim toho mnoho neudelame. >>>> Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho >>>> generovat neco jako landuse=residential. Vic mne nenapada. >>> stavební objekty mají v datech i hranice, proto se na to ptám. >> *** kdyz koukam na obec s DKM >> http://vdp.cuzk.cz/vymenny_format/soucasna/20120630_OB_584029_UZSZ.xml.gz >> >> tak v >> /vf:VymennyFormat/vf:Data/vf:StavebniObjekty/vf:StavebniObjekt >> >> vidim >> <soi:Geometrie><soi:DefinicniBod><gml:Point ... >> >> rikam to spravne? > uzsz jsou jen základní data bez originálních hranic, obsahují jen > definiční body. musíš v tom formuláři nastavit kompletní datovou sadu, > pak se ti ve výběru z údajů zaškrtnou i originální hranice. tyhle > soubory pak mají v názvu uksh a obsahují právě i ty hranice objektů. > např se můžeš podívat do souboru 20120630_OB_500291_UKSH.xml.gz, tam > jsou 100%ně. > > já se pomalu pustím do importu kompletní sady dat, takže pak budeme > vědět, u čeho všeho jsou ty geometrie (např. jestli jsou někde i u ulic > apod.).
tak teď koukám, že v 20120630_OB_500291_UKSH.xml.gz jsou i definiční čáry ulic. zobrazit citaci
>> hanoj > ff >
------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120717/9a33c9d2/attachment.bin>

28.1.2013 05:22:50 (#12)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Ahoj řeším podobnou věc, tentokrát RUIAN -> REST backend a při vytváření loaderu dat v PHP/ExtJS jsem narazil pravděpodobně na stejný problém, co jsi řešil, tedy ArcString a Ring v GML, které nejsou v datech linearizovány (definovány pomocí tří bodů), takže parcela s dírou definovanou kruhem nebo obloukem jako WKT neproleze. Možná by ti pomohla pro tvůj loader CurveLinearizer metoda z degree: http://apidoc.deegree.org/3.1.0/apidocs/org/deegree/geometry/linearization/CurveLinearizer.html Martin ----- Original Message ----- From: Miroslav Šulc [mailto:fordfrog na fordfrog.com] To: OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] Sent: Tue, 17 Jul 2012 22:38:15 +0200 Subject: Re: [Talk-cz] problém s gml řetězcem zobrazit citaci
> Dne 17.7.2012 22:10, Miroslav Šulc napsal(a): > > Dne 17.7.2012 21:40, hanoj napsal(a): > >> Dne 17. července 2012 11:01 Miroslav Šulc <fordfrog na fordfrog.com> > napsal(a): > >>> Dne 17.7.2012 00:06, hanoj napsal(a): > >>>>>> PS: dival jsem se, ze ulice ve VFR nemaji geometrii, tudiz nas > vlastne > >>>>>> zajimaji jen: > >>>>>> * parcely zastavene ("druh pozemku kod"= myslim 13 ) > >>>>>> * adresni body > >>>>> a budovy? > >>>> *** budovy jsou... > >>>> a) bud zastavene parcely (dnes delane tracerem v JOSM) > >>>> b) nebo bod stavebniho objektu a s tim toho mnoho neudelame. > >>>> Importovat body s tagem building=yes, mi neprijde dobre. Slo by z toho > >>>> generovat neco jako landuse=residential. Vic mne nenapada. > >>> stavební objekty mají v datech i hranice, proto se na to ptám. > >> *** kdyz koukam na obec s DKM > >> http://vdp.cuzk.cz/vymenny_format/soucasna/20120630_OB_584029_UZSZ.xml.gz > >> > >> tak v > >> /vf:VymennyFormat/vf:Data/vf:StavebniObjekty/vf:StavebniObjekt > >> > >> vidim > >> <soi:Geometrie><soi:DefinicniBod><gml:Point ... > >> > >> rikam to spravne? > > uzsz jsou jen základní data bez originálních hranic, obsahují jen > > definiční body. musíš v tom formuláři nastavit kompletní datovou > sadu, > > pak se ti ve výběru z údajů zaškrtnou i originální hranice. tyhle > > soubory pak mají v názvu uksh a obsahují právě i ty hranice objektů. > > např se můžeš podívat do souboru 20120630_OB_500291_UKSH.xml.gz, tam > > jsou 100%ně. > > > > já se pomalu pustím do importu kompletní sady dat, takže pak budeme > > vědět, u čeho všeho jsou ty geometrie (např. jestli jsou někde i u > ulic > > apod.). > tak teď koukám, že v 20120630_OB_500291_UKSH.xml.gz jsou i definiční > čáry ulic. > >> hanoj > > ff > > > > > >

28.1.2013 05:30:12 (#13)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Oprava... (jsou definovány pomocí tří bodů). ----- Original Message ----- From: Martin Kokeš [mailto:shr3k na typo3-hosting.com] To: OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] Sent: Mon, 28 Jan 2013 17:22:50 +0100 Subject: Re: [Talk-cz] problém s gml řetězcem zobrazit citaci
> datech linearizovány (definovány pomocí tří bodů), takže parcela s

« zpět na výpis měsíce