Search Results

Search found 3 results on 1 pages for 'wageoghe'.

Page 1/1 | 1 

  • Point in polygon OR point on polygon using LINQ

    - by wageoghe
    As noted in an earlier question, How to Zip enumerable with itself, I am working on some math algorithms based on lists of points. I am currently working on point in polygon. I have the code for how to do that and have found several good references here on SO, such as this link Hit test. So, I can figure out whether or not a point is in a polygon. As part of determining that, I want to determine if the point is actually on the polygon. This I can also do. If I can do all of that, what is my question you might ask? Can I do it efficiently using LINQ? I can already do something like the following (assuming a Pairwise extension method as described in my earlier question as well as in links to which my question/answers links, and assuming a Position type that has X and Y members). I have not tested much, so the lambda might not be 100% correct. Also, it does not take very small differences into account. public static PointInPolygonLocation PointInPolygon(IEnumerable<Position> pts, Position pt) { int numIntersections = pts.Pairwise( (p1, p2) => { if (p1.Y != p2.Y) { if ((p1.Y >= pt.Y && p2.Y < pt.Y) || (p1.Y < pt.Y && p2.Y >= pt.Y)) { if (p1.X < p1.X && p2.X < pt.X) { return 1; } if (p1.X < pt.X || p2.X < pt.X) { if (((pt.Y - p1.Y) * ((p1.X - p2.X) / (p1.Y - p2.Y)) * p1.X) < pt.X) { return 1; } } } } return 0; }).Sum(); if (numIntersections % 2 == 0) { return PointInPolygonLocation.Outside; } else { return PointInPolygonLocation.Inside; } } This function, PointInPolygon, takes the input Position, pt, iterates over the input sequence of position values, and uses the Jordan Curve method to determine how many times a ray extended from pt to the left intersects the polygon. The lambda expression will yield, into the "zipped" list, 1 for every segment that is crossed, and 0 for the rest. The sum of these values determines if pt is inside or outside of the polygon (odd == inside, even == outside). So far, so good. Now, for any consecutive pairs of position values in the sequence (i.e. in any execution of the lambda), we can also determine if pt is ON the segment p1, p2. If that is the case, we can stop the calculation because we have our answer. Ultimately, my question is this: Can I perform this calculation (maybe using Aggregate?) such that we will only iterate over the sequence no more than 1 time AND can we stop the iteration if we encounter a segment that pt is ON? In other words, if pt is ON the very first segment, there is no need to examine the rest of the segments because we have the answer. It might very well be that this operation (particularly the requirement/desire to possibly stop the iteration early) does not really lend itself well to the LINQ approach. It just occurred to me that maybe the lambda expression could yield a tuple, the intersection value (1 or 0 or maybe true or false) and the "on" value (true or false). Maybe then I could use TakeWhile(anontype.PointOnPolygon == false). If I Sum the tuples and if ON == 1, then the point is ON the polygon. Otherwise, the oddness or evenness of the sum of the other part of the tuple tells if the point is inside or outside.

    Read the article

  • How to Zip one IEnumerable with itself

    - by wageoghe
    I am implementing some math algorithms based on lists of points, like Distance, Area, Centroid, etc. Just like in this post: http://stackoverflow.com/questions/2227828/find-the-distance-required-to-navigate-a-list-of-points-using-linq That post describes how to calculate the total distance of a sequence of points (taken in order) by essentially zipping the sequence "with itself", generating the sequence for Zip by offsetting the start position of the original IEnumerable by 1. So, given the Zip extension in .Net 4.0, assuming Point for the point type, and a reasonable Distance formula, you can make calls like this to generate a sequence of distances from one point to the next and then to sum the distances: var distances = points.Zip(points.Skip(1),Distance); double totalDistance = distances.Sum(); Area and Centroid calculations are similar in that they need to iterate over the sequence, processing each pair of points (points[i] and points[i+1]). I thought of making a generic IEnumerable extension suitable for implementing these (and possibly other) algorithms that operate over sequences, taking two items at a time (points[0] and points[1], points[1] and points[2], ..., points[n-1] and points[n] (or is it n-2 and n-1 ...) and applying a function. My generic iterator would have a similar signature to Zip, but it would not receive a second sequence to zip with as it is really just going to zip with itself. My first try looks like this: public static IEnumerable<TResult> ZipMyself<TSequence, TResult>(this IEnumerable<TSequence> seq, Func<TSequence, TSequence, TResult> resultSelector) { return seq.Zip(seq.Skip(1),resultSelector); } With my generic iterator in place, I can write functions like this: public static double Length(this IEnumerable<Point> points) { return points.ZipMyself(Distance).Sum(); } and call it like this: double d = points.Length(); and double GreensTheorem(Point p1, Point p1) { return p1.X * p2.Y - p1.Y * p2.X; } public static double SignedArea(this IEnumerable<Point> points) { return points.ZipMyself(GreensTheorem).Sum() / 2.0 } public static double Area(this IEnumerable<Point> points) { return Math.Abs(points.SignedArea()); } public static bool IsClockwise(this IEnumerable<Point> points) { return SignedArea(points) < 0; } and call them like this: double a = points.Area(); bool isClockwise = points.IsClockwise(); In this case, is there any reason NOT to implement "ZipMyself" in terms of Zip and Skip(1)? Is there already something in LINQ that automates this (zipping a list with itself) - not that it needs to be made that much easier ;-) Also, is there better name for the extension that might reflect that it is a well-known pattern (if, indeed it is a well-known pattern)? Had a link here for a StackOverflow question about area calculation. It is question 2432428. Also had a link to Wikipedia article on Centroid. Just go to Wikipedia and search for Centroid if interested. Just starting out, so don't have enough rep to post more than one link,

    Read the article

  • Can output from OutputDebugString be viewed in VisualStudio's output window

    - by wageoghe
    I am using C# and VS2010. When I use OutputDebugString to write debug information, should it show up in the output window? I can see the output from OutputDebugString in DebugView, but I thought I would see it in Visual Studio's Output window. I have looked under Tools-Options-Debugging-General and the output is NOT being redirected to the Immediate window. I have also looked under Tools-Options-Debugging-Output Window and all General Output Settings are set to "On". Finally, I have used the drop-down list in the Output window to specify that Debug messages should appear. If I change Tools-Options-Debugging-General to redirect the output to the Immediate window, the OutputDebugString messages do not appear in the immediate window. Here is my entire test program: using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Runtime.InteropServices; using System.Diagnostics; namespace OutputDebugString { class Program { [DllImport("kernel32.dll", CharSet = CharSet.Auto)] public static extern void OutputDebugString(string message); static void Main(string[] args) { Console.WriteLine("Main - Enter - Console.WriteLine"); Debug.WriteLine("Main - Enter - Debug.WriteLine"); OutputDebugString("Main - Enter - OutputDebugString"); OutputDebugString("Main - Exit - OutputDebugString"); Debug.WriteLine("Main - Exit - Debug.WriteLine"); Console.WriteLine("Main - Exit - Console.WriteLine"); } } } If I run within the debugger, the Debug.WriteLine output does show up in the output window, but the OutputDebugString output does not. If I run from a console window, both Debug.WriteLine and OutputDebugString show up in DebugView. Why doesn't the OutputDebugString output ever show up in the output window? Ultimately, my intent is not to write a lot of debug output with OutputDebugString, rather I will use System.Diagnostics or NLog or something similar. I am just trying to find out, if I configure a logging platform to write to OutputDebugString, will the output be visible from within the debugger. Edit: I went back to my original program (not the simple test above) which uses TraceSources and TraceListeners configured via the app.config file. If I configure the trace sources to write to the System.Diagnostics.DefaultTraceListener (which is documented as writing to OutputDebugString), then the trace source output DOES go to the debug window. However, lines that write directly with OutputDebugString (such as in my simple example) DO NOT go to the debug window. Also, if I use a different TraceListener that writes to OutputDebugString (I got one from Ukadc.Diagnostics at codeplex), that output DOES NOT go to the debug window. Note that I have seen these questions but they did not provide a working solution: here and here

    Read the article

1