> 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.

> 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): >> 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

> 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?

>> 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?

>> 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.

>>> 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

>> 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?

> 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?

>> hanoj > ff

>>> 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

> 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.

> 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?

> hanoj

> 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.).

>> hanoj > ff >

> 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 > > > > > >

> datech linearizovány (definovány pomocí tří bodů), takže parcela s