[Dev] RFC on Buffered* shape syntax for WKT

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Dev] RFC on Buffered* shape syntax for WKT

dsmiley
I'd like some input on how to expressed buffered shapes in a custom/extended WKT syntax.  Here is a plain LineString:
    LineString(1 2, 4 5)
That one just as two points but there could certainly be many more.  It might represent a road or the path of some object, or whatever.  But as-is, it doesn't have any area, and would be extremely unlikely to intersect with a point, for example.

Here are two proposed syntaxes to buffer the previous shape by 7. 
Syntax A:
    BufferedLineString(7, (1 2, 4 5))
Syntax B: 
    Buffer(7, LineString(1 2, 4 5))

I could go either way, but FWIW I've already implemented 'A'.  There isn't a standard for this, but we can try and fit in with the existing WKT standard and other extensions as much as possible.  It just so happens that I have a custom BufferedLineString shape but that shouldn't affect the 'A' or 'B' choice.  For a JTS context, we could offer buffer support for any shape in WKT -- the JTS's buffer operation is just a method call away.

Future similar extensions might be BBox*.  Geometry simplification[1] (e.g. reducing vertices on a polygon) given a JTS context might be supported with yet another method (e.g. Simplify(...)).  Although in that latter case, I think it would more likely be configured built into the context so that it always happens according to some sort of configurable heuristic on the size of the shape.  JtsGeoStrategy does this at the SpatialStrategy level.

As an aside, it seems we could express a circle with Buffer(3, Point(1 2)) -- right?  Or this syntax:  BufferedPoint(3, (1 2))

[1]: TopologyPreservingSimplifier.simplify(geometry,tolerance)

~ David

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] RFC on Buffered* shape syntax for WKT

Chris Male



On Wed, Nov 14, 2012 at 10:31 AM, [hidden email] <[hidden email]> wrote:
I'd like some input on how to expressed buffered shapes in a custom/extended WKT syntax.  Here is a plain LineString:
    LineString(1 2, 4 5)
That one just as two points but there could certainly be many more.  It might represent a road or the path of some object, or whatever.  But as-is, it doesn't have any area, and would be extremely unlikely to intersect with a point, for example.

Here are two proposed syntaxes to buffer the previous shape by 7. 
Syntax A:
    BufferedLineString(7, (1 2, 4 5))
Syntax B: 
    Buffer(7, LineString(1 2, 4 5))

I think Syntax A makes the most sense.  It's explicit and easy to parse.  I don't think Shape definition languages should be too fancy.
 

I could go either way, but FWIW I've already implemented 'A'.  There isn't a standard for this, but we can try and fit in with the existing WKT standard and other extensions as much as possible.  It just so happens that I have a custom BufferedLineString shape but that shouldn't affect the 'A' or 'B' choice.  For a JTS context, we could offer buffer support for any shape in WKT -- the JTS's buffer operation is just a method call away.

Future similar extensions might be BBox*.  Geometry simplification[1] (e.g. reducing vertices on a polygon) given a JTS context might be supported with yet another method (e.g. Simplify(...)).  Although in that latter case, I think it would more likely be configured built into the context so that it always happens according to some sort of configurable heuristic on the size of the shape.  JtsGeoStrategy does this at the SpatialStrategy level.

I think we should decouple an operational language from the Shape definition language.  BBox, Simplify and Buffer are operations, arguably that should be done client side but if we have some improved logic then okay.  I dont think we should get into the operational language stuff just yet.
 

As an aside, it seems we could express a circle with Buffer(3, Point(1 2)) -- right?  Or this syntax:  BufferedPoint(3, (1 2))

Good call on expressing a Circle as a buffered point.  I go for BufferedPoint.
 

[1]: TopologyPreservingSimplifier.simplify(geometry,tolerance)

~ David

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com




--
Chris Male | Open Source Search Developer | elasticsearch | www.elasticsearch.com

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] RFC on Buffered* shape syntax for WKT

ryan
In reply to this post by dsmiley
dsmiley wrote
Here are two proposed syntaxes to buffer the previous shape by 7.
Syntax A:
    BufferedLineString(7, (1 2, 4 5))
Syntax B:
    Buffer(7, LineString(1 2, 4 5))
I like option B -- it makes it clear that that it is an operation on more basic geometry.  


dsmiley wrote
As an aside, it seems we could express a circle with Buffer(3, Point(1 2))
-- right?  Or this syntax:  BufferedPoint(3, (1 2))
You *could* but Circle seems much more clear then BufferedPoint!


ryan
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] RFC on Buffered* shape syntax for WKT

dsmiley
On Fri, Nov 16, 2012 at 12:21 PM, ryan <[hidden email]> wrote:
dsmiley wrote
> Here are two proposed syntaxes to buffer the previous shape by 7.
> Syntax A:
>     BufferedLineString(7, (1 2, 4 5))
> Syntax B:
>     Buffer(7, LineString(1 2, 4 5))

I like option B -- it makes it clear that that it is an operation on more
basic geometry.


Okay.
 

dsmiley wrote
> As an aside, it seems we could express a circle with Buffer(3, Point(1 2))
> -- right?  Or this syntax:  BufferedPoint(3, (1 2))

You *could* but Circle seems much more clear then BufferedPoint

Our existing Circle syntax doesn't even look like WKT, with its "d=" named parameter.  Granted that could be rectified with a syntax like Circle((x y), d).  This Circle would be a new non-standardized WKT shape.  The advantage that the Buffer(...) syntax has is that we're talking about the addition of one new (albeit non-standard) operation -- buffer.  And with that, you simultaneously gets the buffer capability but also you can then define a circle.  In this light, I guess I'm also leaning towards Syntax 'B' above.

~ David

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] RFC on Buffered* shape syntax for WKT

Chris Male



On Sat, Nov 17, 2012 at 8:37 AM, [hidden email] <[hidden email]> wrote:
On Fri, Nov 16, 2012 at 12:21 PM, ryan <[hidden email]> wrote:
dsmiley wrote
> Here are two proposed syntaxes to buffer the previous shape by 7.
> Syntax A:
>     BufferedLineString(7, (1 2, 4 5))
> Syntax B:
>     Buffer(7, LineString(1 2, 4 5))

I like option B -- it makes it clear that that it is an operation on more
basic geometry.


Okay.

I don't see BufferedLineString as an operation on a basic geometry.  BufferedLineString is a basic geometry since LineString has no concept of width so there is nothing to buffer.  
 
 

dsmiley wrote
> As an aside, it seems we could express a circle with Buffer(3, Point(1 2))
> -- right?  Or this syntax:  BufferedPoint(3, (1 2))

You *could* but Circle seems much more clear then BufferedPoint

Our existing Circle syntax doesn't even look like WKT, with its "d=" named parameter.  Granted that could be rectified with a syntax like Circle((x y), d).  This Circle would be a new non-standardized WKT shape.  The advantage that the Buffer(...) syntax has is that we're talking about the addition of one new (albeit non-standard) operation -- buffer.  And with that, you simultaneously gets the buffer capability but also you can then define a circle.  In this light, I guess I'm also leaning towards Syntax 'B' above.

I think adding a new Shape type to our WKT is better than opening a can of worms by starting to add operations.
 

~ David

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com




--
Chris Male | Open Source Search Developer | elasticsearch | www.elasticsearch.com

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] RFC on Buffered* shape syntax for WKT

dsmiley

On Nov 16, 2012, at 10:43 PM, Chris Male <[hidden email]> wrote:

I don't see BufferedLineString as an operation on a basic geometry.  BufferedLineString is a basic geometry since LineString has no concept of width so there is nothing to buffer.  

0 width + buffer 10 == 20 across    -- and JTS agrees with this.  Take a LineString and buffer(10) it and you'll get a polygon (with area) as expected.  As I expect any way.  I'm talking about the same thing with a buffer() operation at the WKT level.


_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] RFC on Buffered* shape syntax for WKT

Chris Male
I don't think having a Shape which has no concept of a width and allowing it to be buffered makes much sense but that's me.  I don't think that just because JTS does it we should too.


On Sat, Nov 17, 2012 at 4:50 PM, David Smiley <[hidden email]> wrote:

On Nov 16, 2012, at 10:43 PM, Chris Male <[hidden email]> wrote:

I don't see BufferedLineString as an operation on a basic geometry.  BufferedLineString is a basic geometry since LineString has no concept of width so there is nothing to buffer.  

0 width + buffer 10 == 20 across    -- and JTS agrees with this.  Take a LineString and buffer(10) it and you'll get a polygon (with area) as expected.  As I expect any way.  I'm talking about the same thing with a buffer() operation at the WKT level.


_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com




--
Chris Male | Open Source Search Developer | elasticsearch | www.elasticsearch.com

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com