Hi Martin, Peter,
I retrieved my code and realized that the problem I have tried to solve
is a bit
different from Peter's one.
Let me explain and let see if some low-level modifications could serve
both purposes.
I wanted to build a planar graph from a set of linestrings and get 2 or
3 layers (faces,
edges and eventually nodes) where all geometries would be attributed an
id, and
where the following relations would be held on edges
- initial node
- final node
- left face
- right face
To get it, I had to do the following changes
- pre-process my linework so that it is correctly splitted at intersections
- rewrite EdgeRing where I added a long label attribute (class is
package protected)
- rewrite PolygonizeDirectedEdge where I added a startNode label
- rewrite PolygonizeGraph which have several private methods I had to
change so that
they accept my new EdgeRing and PolygonizeDirectedEdge
- Polygonizer : I added 2 attributes labeledEdgeList and nodeList. I
rewrote polygonize
(maybe I could have add a method) so that
* it does not remove dangles and cutedges
* while building polygons (and nodes) I use userData to set labels
from edgeRingLabel
(or PolygonizeDirectedGraph.startNode label for nodes)
*...
(I can send my changes if needed)
I'm wondering if such modifications could also serve Peter's problem.
My first thought when I did that changes is that I could probably have
extended
some class/methods and done less copy/paste if some methods had been
public or
protected.
It would need more thought to check if such a modification could also
serve Peter's
purpose. I think once edge to face relation computed, it would be quite
easy to get
face to edgelist. Not sure if I could have preserved user UserData as I
also used it in
my code to transfer element's id.
Sorry i I'm a bit confused, it would probaby need more work to get a
nice solution
able to serve multiple purposes.
Michaël
That would be great if you can provide some suggestions, Michael.
My best idea for meeting Peter's requirement for preserving edge
information is to add an option to the polygonizer to keep lists of
the edge userdata as I outlined in my email. This could be
incorporated in the Polygonizer as it stands. And perhaps you have
some further ideas for making the Polygonizer more flexible.
On Tue, Nov 25, 2014 at 11:10 PM, Michael Michaud
<[email protected] <mailto:[email protected]>> wrote:
Hi,
> Well, the original linestrings and the border/polygon hole line strings
wouldn't necessarily be equal,
correct? One option would be to first dissolve the line strings
into segments, so that all resulting line strings were one segment
long. Construct the hashmap from that set. Then after
polygonization, you could walk the segments of the polygon
linestrings and use the hashmap to determine the values of
contributing line strings. If line string values are not unique,
this method would require some tweaking.
A few years ago, I had a similar problem where I wanted to keep
relations between polygon and enclosing edges after polygonization. I
had to hack Polygonizer. I hoped it would not be too much work, but
because Polygonizer made many low-level methods private, I had to
duplicate several classes.
I think it would make things easier if Polygonizer itsef coud preserve
information where it is possible, or if it could expose more
methods in
its api. I'll try to give more details about what I had to change,
if I
can retrieve it.
Michaël Michaud
>
>
>
>> On Nov 25, 2014, at 4:48 PM, Michael Bedward
<[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi Peter,
>>
>> Perhaps a HashMap of LineString -> Double will do the trick ?
>>
>> Michael
>>
>>> On 26 November 2014 at 05:29, Peter Kovac
<[email protected]
<mailto:[email protected]>> wrote:
>>> Hi JTS,
>>>
>>> I'm computing a polygonization of a large set of LineStrings
(tens to
>>> hundred thousands), each with one Double value as user data.
What is the
>>> most efficient way to determine for each resulting polygon the
set of
>>> Double values of LineStrings which are the borders of the polygon?
>>>
>>> Can I find by extending the Poylgonizer somehow (I think it's
unlikely)?
>>> Currently, I keep the input LineStrings in a SpatialIndex and
query each
>>> polygon coordinate for LineStrings containing it, but it's a
very slow
>>> process (tens of seconds).
>>>
>>> For example:
>>> Let's give LineStrings in this MULTILINESTRING ((10 0, 0 0, 0
20, 10
>>> 20), (10 0, 20 0, 20 20, 10 20), (10 0, 10 20)) values 1, 2, and 3
>>> respectively.
>>> Then the set of values of POLYGON ((10 20, 10 0, 0 0, 0 20, 10
20)) is
>>> {1, 3} and of POLYGON ((10 20, 20 20, 20 0, 10 0, 10 20)) is
{2, 3}.
>>>
>>> Thank you,
>>>
>>> --
>>> Peter Kovac
>>> MicroStep-MIS
>>> Programmer
>>> [email protected] <mailto:[email protected]>
>>> http://www.microstep-mis.com
>>>
>>>
>>>
------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and
Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App
Integration & more
>>> Get technology previously reserved for billion-dollar
corporations, FREE
>>>
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Jts-topo-suite-user mailing list
>>> [email protected]
<mailto:[email protected]>
>>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>
------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and
Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App
Integration & more
>> Get technology previously reserved for billion-dollar
corporations, FREE
>>
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Jts-topo-suite-user mailing list
>> [email protected]
<mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
Dashboards
> with Interactivity, Sharing, Native Excel Exports, App
Integration & more
> Get technology previously reserved for billion-dollar
corporations, FREE
>
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Jts-topo-suite-user mailing list
> [email protected]
<mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and
Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration
& more
Get technology previously reserved for billion-dollar
corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
