POLYGON((38591455.29279993 3341853.182999084,38591450.89579993 3341845.826799084,38591447.82339992 3341841.763499084,38591444.25549993 3341839.186599084,38591438.30899993 3341835.420499084,38591431.17329992 3341830.663199084,38591425.92059992 3341827.491799084,38591420.66799992 3341825.311299084,38591415.11799993 3341823.130899084,38591407.68499993 3341821.346799084,38591392.42249992 3341820.553599084,38591385.18769993 3341820.652699084,38591378.64659993 3341821.148199084,38591372.99739993 3341823.427499084,38591367.84379993 3341825.607699084,38591359.61789992 3341830.067399084,38591353.27509993 3341835.419099084,38591346.04029992 3341841.662799084,38591341.97689992 3341846.915399084,38591341.94539993 3341846.960399084,38591342.04339992 3341846.323199084,38591343.00349993 3341843.778899084,38591343.73089992 3341842.414999084,38591346.47509993 3341839.010199084,38591350.05039992 3341834.593599084,38591353.06749993 3341830.744199084,38591357.87139992 3341825.470399084,38591361.05119993 3341821.797199084,38591362.40669993 3341819.086199084,38591363.21739992 3341816.190599084,38591363.50569993 3341812.962199084,38591363.20969993 3341810.357599084,38591360.30869993 3341801.171199084,38591371.32279993 3341795.566099084,38591375.94139992 3341793.466799084,38591383.91889992 3341789.897899084,38591388.32759993 3341785.489199084,38591390.84679992 3341782.550099084,38591391.26669993 3341779.401099084,38591392.52629992 3341773.942799084,38591391.26669993 3341769.114199084,38591388.53749993 3341765.545299084,38591382.44939993 3341758.407499084,38591379.09039993 3341754.208799084,38591373.84199993 3341748.750499084,38591367.33909993 3341740.637799084,38591387.15579993 3341726.546999084,38591396.74579993 3341719.344999084,38591411.61689992 3341725.799199084,38591415.32769992 3341730.341499084,38591425.40409993 3341745.887799084,38591444.59719992 3341772.694299084,38591465.04749992 3341797.807099084,38591484.18029992 3341812.844799084,38591490.56789993 3341818.880799084,38591498.12989993 3341826.026599084,38591500.89919993 3341829.437899084,38591502.54519992 3341831.465399084,38591503.18509992 3341836.520599084,38591506.00059993 3341847.846699084,38591508.36819992 3341854.757499084,38591508.30419993 3341861.732299084,38591507.28029992 3341866.851299084,38591502.81739993 3341868.928799084,38591497.42619993 3341870.370799084,38591491.85909992 3341870.114999084,38591485.65209992 3341868.898999084,38591465.03899992 3341858.196099084,38591455.70519993 3341853.349499084,38591455.29279993 3341853.182999084))
Why is this polygon judged to be a self-intersecting figure?
If it is the accuracy problem that causes the judgment to be self-intersecting, how can I make the judgment during storage, or please tell me what is the accuracy of the self-intersecting graphics?
Because I don't know why the ES database judged this polygon to be self-intersecting, I don't know what to do with it.
I am not an expert but I'll see if I can see check with somebody in the geospatial area.
I do notice it's 16 significant digits That seems like quite a bit.
I do get the same error as you.
Also, is there any chance you could convert that to lat/ lon so I could take a look? I'm not as familiar with the coordinate system...
Hello, stephenb.
Converting to lat/lon coordinate system can be stored successfully, but I don't understand why I can't store my polygon in the current projected coordinate system. I use tools to detect that the polygon is not self-intersecting. What I want to know is why es judged the polygon to be problematic.
POLYGON((114.949676283338 30.1926730429342,114.9496299932314 30.19260702434834,114.9495977412952 30.19257060644386,114.949560473327 30.19254763235763,114.9494984058409 30.19251411109607,114.9494239053577 30.19247173907544,114.9493690930305 30.19244352948973,114.9493143675076 30.19242425728923,114.9492565541613 30.19240500831906,114.9491792242599 30.19238947525895,114.9490206877623 30.1923834678903,114.9489455786626 30.19238490531136,114.9488777064082 30.19238986590188,114.9488192488486 30.19241084843153,114.9487659284256 30.19243089987509,114.9486809058964 30.19247174200627,114.9486155123452 30.19252048804194,114.9485409343456 30.19257734642634,114.9484991987633 30.19262502738714,114.9484988755936 30.19262543563002,114.9484998380278 30.19261968104781,114.9485095866498 30.19259666064339,114.9485170212248 30.19258430432651,114.9485452194825 30.19255338865834,114.948581959426 30.19251328464011,114.9486129526801 30.19247833839432,114.9486623748007 30.1924304105667,114.9486950725222 30.19239704131692,114.9487089120331 30.19237248764891,114.9487170790132 30.19234630990298,114.9487197932272 30.19231716970825,114.9487164946986 30.19229369976397,114.9486855798446 30.19221106097104,114.9487994524376 30.1921596784626,114.9488472249064 30.19214039687654,114.9489297450386 30.19210760787189,114.9489751383659 30.19206751238775,114.9490010404868 30.19204081390941,114.9490051278536 30.19201237996944,114.9490177339013 30.19196305421657,114.9490042381103 30.19191959732368,114.9489755927599 30.1918876127045,114.9489117640862 30.19182369075426,114.9488765252634 30.19178607294895,114.9488215603563 30.1917372361115,114.9487533408156 30.19166455213164,114.9489578740016 30.19153597151574,114.9490568215062 30.19147029255905,114.949211782473 30.19152738869372,114.9492507036998 30.19156807906881,114.9493566694609 30.19170754151022,114.9495582665986 30.1919478798063,114.9497727713709 30.19217284690994,114.9499727254248 30.19230704044323,114.9500395693417 30.19236100164661,114.9501187030264 30.1924248843018,114.9501477516032 30.19245544416888,114.9501650173237 30.19247360736205,114.9501720990836 30.19251915455606,114.9502023128465 30.19262109840369,114.950227493797 30.19268325218036,114.9502274333599 30.19274616614135,114.9502172456858 30.19279241394798,114.9501710879115 30.19281148769409,114.9501152366688 30.19282489937025,114.9500574120478 30.19282301096204,114.9499928602906 30.1928125101436,114.9497779106751 30.19271752568649,114.9496805796389 30.19267451367092,114.949676283338 30.1926730429342))
As stated in the documentation, shape field type uses single precision floating point values. In your projected coordinate system you need to support up to 16 significant digits which cannot be represented in single precision. sorry to say but it won't work.
Thank you for your reply. Can I understand that the ES storage polygon only supports 15 significant digits, and 16 or more significant digits cannot be guaranteed
This 9-digit significant number cannot be stored. Is it possible to store polygon actual significant digits that cannot exceed 8 significant digits?
POLYGON((100.000022 100.000022,100.000024 100.000022,100.000024 100.000024,100.000022 100.000024,100.000022 100.000022))
geo_shape field uses double precision and supports up to 15 significant digits. shape field uses single precision and supports up to 7 significant digitsm
Thank you very much for your reply.
The number of significant digits supported by the geo_shape field you describe here is significantly higher than that of the shape field. Why do I have a higher success rate of storing the shape field when storing the same batch of data?
I don't know without an example, could you provide a polygon example that works for shape but it fails for geo_shape?
POLYGON((38590826.64099993 3339519.679299084,38590821.34629992 3339515.936099084,38590807.49179993 3339502.394599084,38590792.47909992 3339495.695399084,38590784.36159992 3339489.117399084,38590779.32319993 3339483.239199084,38590777.45709992 3339478.387399084,38590777.89089993 3339468.175099084,38590777.26109993 3339441.513299084,38590776.63129993 3339414.851499084,38590775.16179992 3339365.516599084,38590772.43259992 3339348.721799084,38590769.70339993 3339333.396499084,38590766.75089993 3339321.528299084,38590768.14769992 3339323.204399084,38590772.74859992 3339328.725499084,38590776.94709992 3339336.042599084,38590778.74629992 3339342.160299084,38590780.06569993 3339348.757499084,38590780.78559992 3339354.155599084,38590781.74499992 3339363.391899084,38590783.18459993 3339371.428899084,38590783.66439992 3339377.066699084,38590783.90419993 3339382.704299084,38590784.14419992 3339388.701999084,38590785.22389992 3339396.139199084,38590787.98269992 3339402.376699084,38590793.38059992 3339410.533499084,38590797.69889992 3339417.250799084,38590800.93759993 3339420.969399084,38590800.99229992 3339421.125599084,38590803.45659993 3339428.166599084,38590806.33559993 3339436.083499084,38590808.85459992 3339442.441099084,38590813.29279993 3339449.278399084,38590819.65029993 3339461.513599084,38590824.80839992 3339472.069399084,38590826.72759993 3339478.906799084,38590827.44729993 3339485.144399084,38590827.56719992 3339491.141999084,38590827.34889992 3339498.785799084,38590827.49039993 3339502.939999084,38590826.61149993 3339519.101899084,38590826.64099993 3339519.679299084))
I see where the confusion is and I thought we were more explicit on the documentation.
For 'geo_shape` field, Elasticsearch only supports WGS84 coordinates. It is said here in the documentation although I think it should be more clear.
Just for curiosity, is there any reason you want to store your data in a coordinate system different to WGS84? Maybe if you explain your use case we can help you better here.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.