Hi Curt,
I haven't yet spent 100s of hours yet, but my computer has (testing some
more problem detectors in terragear). Most of these were to address issues
when building the apt.dat version 850 parser. It's certainly not fun.
20,000 airports, and you can get it down to 4 or 5 that crash
triangulation. So you look at the poly that crashes, and see some issue
that may or may not be the root cause. modify, test the offending airport
and it works! Retest all 20,000, and you end up with 5 different crashes
on 5 different airports. rinse and repeat. over and over.
I think I have a 'solution' now that works 'good enough'. If I snap to a
1cm grid, I get all but a few airports working - If i slightly modify the
grid (either 1/2 cm, or 1/4 cm), I can get the rest.
I've used a lot of these solutions as well when using Corrine and OSM data
in fgfs-construct with similar results.
I think the best solution is a combination of the two - using Martin's
GRASS work to fix as many issues as possible, and increasing the robustness
of terragear to handle anything that falls through the cracks.
Also, There's another clipping library that we've been experimenting with
that uses int64 for vertices, instead of fp. It certainly helps in some
situations, and the author is still actively maintaining the library. He
is willing to accept problems we find.
Pete
On Tue, Mar 13, 2012 at 11:45 AM, Curtis Olson <curtol...@gmail.com> wrote:
> Hi Martin,
>
> Ok, understood. I just wanted to make sure what I imagined "topologically
> clean" might mean matched your usage. :-)
>
> So really, much of the terragear code itself is there to create a
> topologically clean data set from a plethora of inputs from a wide variety
> of sources.
>
> The problem is that the terragear mechanism uses the GPC polygon clipping
> library -- and real world GIS data imposes every nasty degenerate case you
> can imagine -- and does it at the limits of floating point resolution. In
> some ways you can think of this as inconsistencies that are too small for
> the GPC library to detect so that leads to non-topologically consistent
> results.
>
> This can lead to any number of problems -- ranging from crashing GPC
> itself to crashing just about any of the down stream code.
>
> I've spent hundreds of hours (probably) investigating individual cases and
> crafting detection/fixing code for a variety of types of problems. But as
> you increase the resolution of the data, you just increase the number of
> these problems, probably stack them on top of each other in some cases, and
> probably invent some new ones I hadn't seen in the lower res data.
>
> Well, it's just a whole lot of fun. :-)
>
> And you could create a topologically clean land cover database which is a
> good thing. But then try to mix this with some other dataset (airports
> from Robin for instance) and be right back to having topological problems
> again.
>
> I have been wondering if some sort of rasterized painting algorithm would
> be simpler and more robust (at the expense of some resolution.) And this
> could be done "offline" and not involve opengl or rendering at all -- just
> big 2D arrays. Essentially paint a big image from bottom to top using your
> polygon data, and then extract the result into actual polygons -- kind of
> the same process as we do now, but do it in raster space rather than vector
> space. Every once in a while I've wondered if we've made the problem too
> hard for ourselves and maybe we should be seeking a bit simpler solution
> and learn to live with some different set of trade offs?
>
> Best regards,
>
> Curt.
> On Mar 13, 2012 8:26 AM, "Martin Spott" <martin.sp...@mgras.net> wrote:
>
>> Curtis Olson wrote:
>>
>> > Just a dumb question: can you give a brief summary of what
>> "topologically
>> > clean" means?
>>
>> I guess you always wondered why I've been pounding on these datasets
>> for so long ;-)
>>
>> Martin.
>> --
>> Unix _IS_ user friendly - it's just selective about who its friends are !
>> --------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
