I'd like to understand the meaning of this error:
Error: ERROR: GEOSUnaryUnion: TopologyException: side location conflict at 509222.06405540626 166742.77073020922
SQLState: XX000
ErrorCode: 0
Given from the following query:
select ST_union(z.geom) from zaz z
Postgis version:
POSTGIS="2.1.0 r11822"
GEOS="3.3.6-CAPI-1.7.6"
PROJ="Rel. 4.8.0, 6 March 2012"
GDAL="GDAL 1.9.2, released 2012/10/08"
LIBXML="2.9.0" RASTER
The problem can be reproduced with this query:
select ST_AsText(ST_Union(z.geom)) from (
select ST_MPolyFromText('MULTIPOLYGON(((513571.981531803 166341.349774259,513116.037800698 166090.997380913,513119.013934713 166083.021341753,513122.34720481 166072.188213938,513124.013839858 166065.997855187,513126.037610988 166046.950597491,513126.037610988 166023.974842894,513117.942526467 165913.024566813,513116.990163582 165897.905806017,513104.966582162 165803.502835059,513104.60944608 165716.718767181,513124.013839858 164966.018723224,513054.967530709 164991.018248951,513040.682087437 164995.065791211,512771.639572476 165072.207184881,512658.070298462 165089.230671447,512620.332919151 165094.825803396,512222.007142577 165144.705809488,512088.319202621 165158.396025957,511825.467046411 165185.300277453,511437.260125488 165216.25207121,511039.767666438 165238.394508282,510637.275302243 165245.299139197,510278.115449307 165247.084819606,509844.671291355 165243.275368066,509480.630578634 165236.01360107,509195.516939992 165227.918516549,508870.642150909 167051.217259529,509104.804375213 166841.340288788,509222.064055406 166742.770730209,509415.631811745 166631.106181965,509727.887792604 166450.871506013,509849.6711965 166401.824817445,509922.407911828 166380.753788619,509986.811451913 166352.659083516,510105.975857876 166299.445807327,510225.259309199 166266.232151719,510464.302393288 166229.209044572,510544.777057055 166213.495056973,510668.227095999 166170.876817877,510762.034840154 166140.282160202,510828.938332812 166126.949079815,510890.365738883 166118.139723131,510959.05491195 166107.782776758,511018.33950153 166100.16387368,511066.076691131 166092.42592524,511097.742757051 166089.211700504,511281.786884542 166098.021057189,511590.471504583 166137.90125299,511730.825984733 166143.853521021,511766.896728995 166143.972566381,511806.419788715 166145.520156069,511905.108392654 166136.353663303,512001.535134742 166108.735139643,512202.95988488 166038.379331527,512434.145975169 165984.332737814,512507.120781218 165968.618750214,512581.643176955 165965.642616199,512654.379892283 166077.307164444,512784.496471421 166043.855418115,512787.948786879 166078.973799492,512787.948786879 166078.973799492,512767.830120937 166133.377529288,512774.020479688 166276.23196201,512799.020005415 166301.350533097,512836.400248644 166276.946234174,512874.018582594 166305.040939276,512838.066883692 166334.564188705,512845.090559968 166427.895751417,512806.996044575 166460.990361664,512846.757195016 166499.561058499,512858.899821797 166718.723567368,512820.329124962 166737.770825064,512833.900296071 166747.532544633,512821.043397126 166755.984765236,512877.708988772 166768.365482739,512893.899157814 166775.627249735,512930.68417424 166780.270018799,512977.469000957 166786.103241468,513181.393703668 166834.554703233,513269.011089071 166852.054371242,513314.605462182 166864.077952663,513568.886352428 166930.624309239,513908.760856946 167004.313387452,513964.593131069 167015.265560627,514336.967019032 167086.454686267,514356.252367449 167090.264137806,514374.10917154 167095.621179034,514433.274715759 166842.649787754,514423.036814747 166834.554703233,514403.037194166 166819.197851716,514302.443864457 166749.675361124,513950.664823878 166560.750373849,513571.981531803 166341.349774259)))') as geom
union
select ST_MPolyFromText('MULTIPOLYGON(((509658.841483455 166823.126348616,509700.031178223 166767.055983772,509737.292376092 166816.816944504,509780.982023433 166778.008156947,509821.338400677 166825.269165106,509862.051914003 166803.960045559,509727.887792604 166450.871506013,509415.631811745 166631.106181965,509480.987714716 166813.959855849,509442.417017881 166923.362542242,509390.751331379 167281.570032294,509425.988758117 167342.997438364,509448.012149829 167345.97357238,509478.963943585 167352.04488577,509503.963469312 167355.021019785,509530.986766168 167357.9971538,509555.986291895 167357.9971538,509583.961951636 167358.949516685,509588.009493897 167357.9971538,509603.009209333 167068.955018259,509651.579716458 167025.622507,509658.841483455 166823.126348616)),((509222.064055406 166742.770730209,509288.967548065 167023.955871951,509248.373080099 167078.002465664,509288.967548065 167023.955871951,509222.064055406 166742.770730209)))') as geom
) z
I'd also like to know if there is a way to "fix" one of the geometries to avoid
the error.
Strangely, if I create a table with a union of the two above selects, and then run an ST_Union, then it doesn't fail.
ST_MakeValid solves the problem.
The result can be passed to ST_Union:
ST_Union(st_makeValid(t.geom))
For the explanation, it could not be better than this one: PostGIS: Tips for power users.
Related
I am querying data from a internally stage file in snowflake as below -
I get the following error:
SQL compilation error: Format argument for function 'TO_TIMESTAMP_TZ' needs to be a string
Any idea what could be going wrong here?
Thanks
SELECT
TO_VARCHAR(stg.$10),
TO_VARCHAR(stg.$45),
TO_NUMBER(stg.$1,20),
TO_NUMBER(stg.$18,20),
TO_VARCHAR(stg.$8),
TO_VARCHAR(stg.$42),
TO_NUMBER(stg.$19,20),
TO_VARCHAR(stg.$11),
TO_VARCHAR(stg.$16),
TO_VARCHAR(stg.$49),
TO_TIMESTAMP_TZ(stg.$47::STRING,'21'),
TO_TIMESTAMP_TZ(stg.$50::STRING,10),
TO_VARCHAR(stg.$48),
TO_NUMBER(stg.$36,19,6),
TO_NUMBER(stg.$27,19,6),TO_VARCHAR(stg.$12),
TO_TIMESTAMP_TZ(stg.$13::STRING,10),
TO_TIMESTAMP_TZ(stg.$5::STRING,10),
TO_NUMBER(stg.$22,20),
TO_NUMBER(stg.$21,19,6),
TO_NUMBER(stg.$20,19,6),
TO_TIMESTAMP_TZ(stg.$2::STRING,10),
TO_NUMBER(stg.$39,19,6),TO_VARCHAR(stg.$35),
TO_VARCHAR(stg.$4),
TO_NUMBER(stg.$40,19,6),
TO_NUMBER(stg.$32,19,6),
TO_NUMBER(stg.$33,19,6),
TO_VARCHAR(stg.$34),
TO_VARCHAR(stg.$37),
TO_VARCHAR(stg.$38),
TO_VARCHAR(stg.$17),
TO_VARCHAR(stg.$23),
TO_NUMBER(stg.$14,19,6),
TO_NUMBER(stg.$28,19,6),
TO_NUMBER(stg.$29,19,6),
TO_NUMBER(stg.$41,6,2),
TO_VARCHAR(stg.$31),
TO_NUMBER(stg.$30,19,6),
TO_VARCHAR(stg.$24),
TO_VARCHAR(stg.$25),
TO_NUMBER(stg.$26,19,6),
TO_VARCHAR(stg.$9),
TO_TIMESTAMP_TZ(stg.$3::STRING,10),
TO_VARCHAR(stg.$15),
TO_VARCHAR(stg.$44),
TO_VARCHAR(stg.$43),
TO_VARCHAR(stg.$53),
TO_TIMESTAMP_TZ(stg.$51::STRING,10),
TO_TIMESTAMP_TZ(stg.$50::STRING,10),
TO_VARCHAR(stg.$52),
TO_TIMESTAMP_TZ(stg.$7::STRING,10),
TO_TIMESTAMP_TZ(stg.$6::STRING,10),
'T_RPDB_POLICY_1_0_0',
TO_TIMESTAMP_TZ(CURRENT_TIMESTAMP::STRING)
FROM '#INTERNAL_POLICY_STAGE/T_RPDB_POLICY.CSV.gz' (file_format => '"JVCO"."STAGING".CSV') stg;
Try
select to_timestamp_tz(CURRENT_TIMESTAMP::string)
Second argument is format(varchar type) and you are passing number.
select to_timestamp_tz('04/05/2013 01:02:03', 'mm/dd/yyyy hh24:mi:ss');
https://docs.snowflake.com/en/sql-reference/functions/to_timestamp.html
I get Error Number: 22001/8152
SQL [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]String or binary data would be truncated.
that means
one of my columns in the source table is bigger than my destination columns.
unfortunately that messsage not display which column is it who , I work with much table columns structure it is about 161 column. I think checking one by one my parameter value and column size is not good deal.
is there fastest way to do that?
this is my inssert query look like
INSERT INTO "my_db"."dbo"."my_table" ("Indeks_Keterpaduan", "NA", "admin_pembiayaan", "adopt_b2", "aktivitas_id", "aktivitas_nama", "assessment", "catatan", "dba_", "dlokasi", "dukungan_kawasan", "ikk_id", "ikk_nama", "ikp_id", "ikp_nama", "isu_strategis_id", "isu_strategis_nama", "jaringan_jalan", "jenis_arahan", "jenis_kegiatan", "jenis_kontrakID", "jenis_kontrakNama", "jenis_kotrakKode", "jenis_sub_aktivitas", "kabkot", "kawasan_nama", "kecamatan_id", "kegiatan_id", "kegiatan_nama", "ket_lokasi", "keterangan", "kewenangan", "kode_ssp", "kode_sspn", "kpk", "kws_kode", "outcome_id", "outcome_nama", "output_id", "output_nama", "param_a", "param_b", "param_c", "param_d", "param_e", "param_total", "phln", "politik_anggaran", "prioritas", "program_id", "program_nama", "provinsi_id", "rc_DED", "rc_DEDalokasi", "rc_DEDsatuan", "rc_DEDvol", "rc_Dokling", "rc_Doklingalokasi", "rc_Doklingsatuan", "rc_Doklingvol", "rc_FS", "rc_FSalokasi", "rc_FSsatuan", "rc_FSvol", "rc_dokptanah", "rc_kesesuaian_rtrw", "rc_konstruksi", "rc_konstruksialokasi", "rc_konstruksisatuan", "rc_konstruksivol", "rc_lahan", "rc_lahanalokasi", "rc_lahansatuan", "rc_lahanvol", "rc_masterplan", "rc_pnp1", "rc_pnp2", "rc_proposalpnp", "rc_rdtr", "rc_rdtralokasi", "rc_rdtrsatuan", "rc_rdtrvol", "rc_rispam", "rc_rispamalokasi", "rc_rispamsatuan", "rc_rispamvol", "rc_rp2kpkp", "rc_rp2kpkpalokasi", "rc_rp2kpkpsatuan", "rc_rp2kpkpvol", "rc_rtbl", "rc_rtblalokasi", "rc_rtblsatuan", "rc_rtblvol", "rc_sddt", "rc_skbup", "rc_skbupalokasi", "rc_skbupsatuan", "rc_skbupvol", "rc_skma", "rc_skt", "rc_spb", "rc_spd", "rc_spp", "readines", "rmp", "rpm", "sa1thn_id", "sajp_id", "sastra_id", "sastra_uraian", "satuan_output", "sbsn", "score_admin_pembiayaan", "score_jaringan_jalan", "score_kpk", "score_politik_anggaran", "score_readines", "sinkronisasi", "status", "status_konreg", "status_rakor", "status_verifikasi", "sub_aktivitas", "subkawasan_nama", "suboutput_id", "suboutput_nama", "sumber_arahan", "sumber_dana", "sumber_data_lainnya", "sumber_input_data", "tahun_anggaran", "tapisan", "time_create", "time_update", "total_score", "unit_id", "unit_nama", "uraian_ssp", "uraian_sspn", "user_create", "user_update", "volume", "waa_", "wab_", "wac_", "wba_", "wbb_", "wbc_", "wca_", "wcb_", "wcc_", "wda_", "wdb_", "wdc_", "wps_kode", "wps_nama", "x", "y")values (value1,value2,...,value (n))
Unfortunately, prior to SQL Server 2019, there's no easy way to pinpoint the cause of error msg 8152 "String or Binary data would be truncated".
While not an ideal solution (but it could save your sanity!), what you could do is install a local, side-by-side preview instance of SQL Server 2019, and run your application against it just to get the exact cause of the error!
Ref: String or Binary data would be truncated: replacing the infamous error 8152
Below query is matching if the partner code below is having asset code, but if no match its not showing it.
i need even if the partner_code is not having asset code to show any result null or 0
select Asset_code, partner_code from Asset
where PARTNER_CODE in ('28800330',
'28800332',
'28800014',
'41900139',
'28800210',
'29200298',
'29200149',
'29200259',
'29200086',
'29400280',
'29000314',
'29000224',
'29600306',
'29100045',
'29800530',
'29800543',
'29900474',
'29700298',
'27400112',
'27400648',
'27400668',
'85400058',
'27300472',
'53200002',
'27800221',
'27800039',
'27200013')
I am trying to use the application oecosimu in Vegan package.
library(sna)
library(permute)
library(lattice)
library(vegan)
library(bipartite)
bio<-read.csv("/home/vicar66/Raw_data/Jan12/98percents_April_16/otu_table/Chapter1/no_bloom_bio_data_L3.txt")
rownames(bio)<-bio[,1]
bio[,1]<-NULL
bio_m<-as.matrix(bio)
a<-oecosimu(bio_m,bipartite::C.score,"swap")
but I keep having this error message:
Attaching package: 'bipartite'
The following object is masked from 'package:vegan':
nullmodel
Error in rowSums(x) : 'x' must be an array of at least two dimensions
Calls: oecosimu -> nullmodel -> rowSums
Execution halted
demo data:
Ciliophora Dinoflagellates MALVs Choanoflagellida
DNAHIN5m 0.062469804 0.826323018 0.031084701 0.000323747
DNAHIN35m 0.045216826 0.595750636 0.187010719 0.000917053
DNAHIN150m 0.018434224 0.204865296 0.531016032 0.017009618
DNAHIN240m 0.016211333 0.889640227 0.04191846 0.03087407
**first column first row is empty. First row are rownames
Anyone have encountered this problem yet?
Thanks!
I have troubles to load data into a geography data type:
DECLARE #g geography;
DECLARE #x xml;
SET #x = '<gml:MultiSurface gml:id="HVO.20584" srsName="urn:ogc:def:crs:EPSG::5514" srsDimension="2" xmlns:gml="http://www.opengis.net/gml/3.2">
<gml:surfaceMember>
<gml:Polygon gml:id="HVO.20584.1">
<gml:exterior>
<gml:LinearRing>
<gml:posList>-747267.00 -1056204.00 -747226.00 -1056232.00 -747239.00 -1056253.00 -747251.00 -1056278.00 -747267.00 -1056315.00 -747291.00 -1056365.00 -747337.00 -1056470.00 -747311.00 -1056474.00 -747244.00 -1056475.00 -747155.00 -1056467.00 -747077.00 -1056501.00 -747112.00 -1057366.00 -747263.00 -1057857.00 -747263.20 -1057857.05 -747263.30 -1057856.60 -747272.50 -1057858.50 -747276.10 -1057850.21 -747285.47 -1057849.89 -747295.34 -1057849.55 -747308.73 -1057848.34 -747320.38 -1057847.28 -747346.97 -1057857.70 -747358.66 -1057860.00 -747374.12 -1057860.55 -747386.06 -1057860.19 -747407.98 -1057859.54 -747444.60 -1057874.26 -747447.75 -1057879.52 -747454.57 -1057890.92 -747674.02 -1057865.46 -747851.54 -1057841.44 -747855.78 -1057838.67 -747871.68 -1057851.47 -747902.20 -1057870.55 -747916.06 -1057881.32 -747934.07 -1057891.87 -747960.03 -1057915.53 -747985.14 -1057954.40 -748001.13 -1057977.02 -748021.22 -1058003.59 -748088.58 -1058092.68 -748104.73 -1058095.49 -748166.00 -1058032.60 -748193.50 -1058002.40 -748214.40 -1057982.20 -748216.40 -1057988.60 -748293.20 -1058053.20 -748297.14 -1058050.03 -748302.55 -1058045.67 -748306.53 -1058042.47 -748311.89 -1058038.15 -748316.50 -1058034.44 -748320.83 -1058030.95 -748330.04 -1058023.54 -748332.15 -1058021.83 -748337.10 -1058017.85 -748341.39 -1058014.39 -748353.30 -1058004.80 -748347.67 -1057996.70 -748338.28 -1057981.31 -748335.70 -1057977.29 -748332.12 -1057971.71 -748330.30 -1057968.92 -748325.55 -1057961.32 -748317.05 -1057947.55 -748310.89 -1057935.02 -748307.10 -1057924.52 -748302.70 -1057912.35 -748298.54 -1057900.12 -748295.48 -1057891.13 -748286.20 -1057862.27 -748278.37 -1057838.25 -748276.55 -1057834.04 -748267.49 -1057808.20 -748264.92 -1057798.33 -748262.21 -1057787.93 -748254.57 -1057761.59 -748251.89 -1057752.13 -748247.59 -1057736.93 -748240.11 -1057716.13 -748237.47 -1057685.67 -748234.93 -1057657.42 -748234.51 -1057652.51 -748234.98 -1057625.54 -748234.51 -1057622.46 -748231.40 -1057602.21 -748233.13 -1057596.29 -748234.13 -1057592.87 -748237.61 -1057582.60 -748238.48 -1057580.02 -748249.72 -1057571.70 -748250.10 -1057571.42 -748252.39 -1057569.73 -748256.83 -1057563.57 -748258.55 -1057540.99 -748250.24 -1057535.67 -748250.94 -1057526.41 -748243.01 -1057522.35 -748236.51 -1057522.75 -748234.73 -1057522.86 -748230.54 -1057518.95 -748211.65 -1057501.36 -748199.48 -1057493.59 -748189.98 -1057489.26 -748179.90 -1057484.66 -748168.54 -1057470.65 -748168.29 -1057470.34 -748165.98 -1057467.49 -748157.92 -1057458.13 -748147.31 -1057450.99 -748146.04 -1057423.54 -748145.40 -1057410.42 -748144.91 -1057400.47 -748144.08 -1057372.43 -748142.62 -1057348.91 -748142.48 -1057347.16 -748141.05 -1057329.37 -748142.26 -1057321.94 -748146.21 -1057304.13 -748148.14 -1057295.42 -748146.30 -1057289.44 -748144.73 -1057284.34 -748141.64 -1057275.31 -748144.63 -1057272.64 -748154.01 -1057247.80 -748151.29 -1057246.55 -748127.50 -1057235.56 -748110.70 -1057228.23 -748082.39 -1057214.75 -748057.48 -1057203.76 -748041.82 -1057196.01 -748029.14 -1057189.74 -748010.10 -1057178.36 -747979.25 -1057161.25 -747957.25 -1057147.63 -747943.14 -1057138.66 -747937.35 -1057131.26 -747926.97 -1057121.60 -747909.48 -1057109.13 -747904.01 -1057106.36 -747895.25 -1057106.99 -747873.33 -1057094.64 -747869.74 -1057093.00 -747851.77 -1057082.31 -747869.79 -1057044.54 -747836.92 -1057032.09 -747795.65 -1057016.73 -747793.70 -1057009.93 -747787.82 -1056992.87 -747781.28 -1056974.44 -747776.81 -1056960.35 -747768.14 -1056933.57 -747762.16 -1056911.71 -747757.80 -1056895.21 -747753.30 -1056877.50 -747749.17 -1056859.18 -747744.25 -1056838.69 -747741.79 -1056821.91 -747739.99 -1056803.90 -747737.12 -1056781.92 -747735.82 -1056761.48 -747735.01 -1056740.42 -747736.57 -1056718.66 -747738.55 -1056694.68 -747741.17 -1056669.07 -747744.02 -1056634.01 -747745.17 -1056623.46 -747748.09 -1056596.69 -747755.37 -1056564.46 -747759.01 -1056547.20 -747761.29 -1056536.38 -747761.56 -1056535.10 -747772.54 -1056491.85 -747774.05 -1056485.90 -747786.35 -1056435.41 -747786.99 -1056433.22 -747796.41 -1056400.93 -747799.01 -1056392.00 -747799.01 -1056392.00 -747799.00 -1056392.00 -747723.00 -1056390.00 -747615.00 -1056374.00 -747596.00 -1056372.00 -747564.00 -1056375.00 -747539.00 -1056382.00 -747513.00 -1056389.00 -747487.00 -1056344.00 -747472.00 -1056316.00 -747458.00 -1056290.00 -747455.00 -1056283.00 -747445.00 -1056265.00 -747433.00 -1056243.00 -747424.00 -1056225.00 -747420.00 -1056218.00 -747412.00 -1056205.00 -747399.00 -1056188.00 -747388.00 -1056173.00 -747383.00 -1056167.00 -747371.00 -1056154.00 -747370.00 -1056153.00 -747362.00 -1056145.00 -747356.00 -1056141.00 -747356.00 -1056140.00 -747334.00 -1056160.00 -747267.00 -1056204.00</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
</gml:MultiSurface>';
SET #g = geography::GeomFromGml(#x, 4326);
I get this exception:
A .NET Framework error occurred during execution of user-defined
routine or aggregate "geography": System.FormatException: 24129: The
given XML instance is not valid because the top-level tag is
gml:MultiSurface. The top-level element of the input Geographic Markup
Language (GML) must contain a Point, LineString, Polygon, MultiPoint,
MultiGeometry, MultiCurve, MultiSurface, Arc, ArcString,
CompositeCurve, PolygonPatch or FullGlobe (geography Data Type only)
object.
What do I need to change in the #x variable to get it working?
Thanks
Note, the answer here refers to the question of dealing with the coordinates above, that are not geodesic, as raised in the comments, and not with the original question of parsing the XML, which was answered in the comments.
After a bit of digging, it seems that the Czech Republic's projection is now known as http://spatialreference.org/ref/sr-org/czech-s-jtsk-gis-esri102067/. If you look at that page you will see that the coordinates are in meters, and are negative, just as in your XML above. This WKT representation gives you information about the datum, spheroid and other characteristics of the projection.
SQL Server does not currently support projecting from one coordinate system to another, so you have two options.
1). Load it as is, but as a geometry not a geography datatype, so your last line above would become
SET #g = geometry::GeomFromGml(#x, 5514);
where 9819 appears to be the SRID code in the above link (although it is all a bit unclear). This actually doesn't matter that much, as you can't convert from one spatial reference system to another, but you will be able to perform any geometry functions on your geometries, such as STIntersects, STContains, STBuffer, etc.
2). Convert it to lat/lon (4326) outside of SQL Server and then import as a geography data type, if that it what you really want. There is as tool called gdaltransform which does this, eg,
gdaltransform -s_srs "+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=0 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +units=m +no_defs" -t_srs EPSG:4326
-747267.00 -1056204.00
24.8307791587916 50.4239544736181 32.0127759873867
14.3847700978484 49.9644982150517 45.4088854994625
where you enter the first line, with the projection info, hit Return, then enter the coordinates and then you get the answer. From this you can see that it is giving a lat/lon 14.38, 49.96, which is in Prague, so definitely the Czech Republic.
This approach isn't very scalable, so you would probably want to look at something like Proj4j which is a Java library for doing coordinate transforms.