Ticket #329 (closed enhancement: fixed)

Opened 3 years ago

Last modified 3 years ago

Improve formatting for GEOSisValidReason_r

Reported by: mwtoews Owned by: geos-devel@…
Priority: minor Milestone: 3.2.1
Component: Default Version: 3.2.0
Severity: Unassigned Keywords:
Cc:

Description

A message from PostGIS's ST_IsValidReason(geometry) shows the message:

Self-intersection[523991 6.5222e+06]

to describe a point with Easting/Northing? coordinates. What I find odd is the mixed conventional numeric and exponential forms.

I can't find the source code for this, but I'm certain there is a "%g %g" formatting code somewhere in there. Although %g is usually a nice formatter, it is unfortunate that it happens to change to exponential form at numbers >=1e+06, which is the range of many projected (i.e., UTM) coordinates (particularly northern ones). [Note, this is probably compiler/platform dependent.]

To make consistent formatting of these coordinates across platforms, and to make it show projected coordinates nicely, I suggest using the formatting code: "%.7g %.7g"

This will use exponential form for numbers >=1e+07, which most earth-based Easting/Northing? coordinates fall within.

Change History

Changed 3 years ago by strk

  • status changed from new to closed
  • resolution set to invalid

ST_isValidReason is a PostGIS function, not GEOS... should file the ticket in there.

Look, I've good news for you:  http://trac.osgeo.org/postgis/changeset/5204

Changed 3 years ago by mwtoews

Ah, that's why I couldn't find it. I had a few bad hints to lead me to think it was a GEOS issue:

  • The NEWS item "IsValidReason? added to CAPI" for  GEOS 3.1.0
  • "elog(ERROR,"GEOS isvalidreason() threw an error!");" in PostGIS's lwgeom_geos.c

I'm not sure if these were mixups between projects or what.

Changed 3 years ago by strk

  • status changed from closed to reopened
  • resolution invalid deleted
  • summary changed from Improve formatting for IsValidReason to Improve formatting for GEOSisValidReason_r

It *is* a mix of the two, as PostGIS's ST_isValid* functions all use GEOS internally. What I was pointing out is that a string for a point is not the best thing to have in return..

Anyway yes, your report is actually valid I guess, so I reopen.

Changed 3 years ago by strk

  • status changed from reopened to closed
  • resolution set to wontfix

But still.. why fix when there's a better alternative ? :) (GEOSIsValidDetail_r)

Changed 3 years ago by pramsey

  • status changed from closed to reopened
  • resolution wontfix deleted
  • milestone set to 3.2.1

It's not in PostGIS, actually, it's in GEOS. PostGIS just consumes the string produced by GEOS.

 http://trac.osgeo.org/geos/browser/trunk/capi/geos_ts_c.cpp#L607

Changed 3 years ago by strk

FYI, the alternative I'm talking about is ST_IsValidDetail, which returns a Geometry object for the location.

Changed 3 years ago by strk

  • status changed from reopened to closed
  • resolution set to fixed

Committed patch giving up to 15 significant digits. r2945 in branch. r2946 in trunk.

Note: See TracTickets for help on using tickets.