![]() ![]() In my implementation, this had the consequence of having my indexed geometries span anywhere from -540 degrees longitude to 540 degrees longitude (with at least a portion of the geometry in the region). Polygon) that overlapped the international date line, I would make sure all of the longitudinal values were unwrapped. When indexing a non-point geometry (e.g. In the January version of GeoMesa, I had implemented an international date line solution for non-point geometries as follows: LineString, Polygon, MultiPoint), and I have recently switched from using a January version of GeoMesa to using a version that is current (as of the last week or so). I currently use GeoMesa to index non-point geometries (e.g. I'll get back to you with some guidance and, if this turns out to be a bug, a JIRA tracking ticket. To: Re: International date line dilemma for non-point geometries, possible bug? This (result of my test) is what you would be expecting, right? So it fails the test I created that should turn that into two linestrings (-180 55, -160 60) (160 50 180 55). I was just looking into using spatial4j rather than the transformations that I have written. I've got a PR up that handles part of this issue. Subject: Re: International date line dilemma for non-point geometries, possible bug? To: Beau Lalonde Geomesa User discussions for example, if I index LINESTRING (-200 50, -160 60), and then query (160 50 180 55), I should get results. an implementation in which my queries can remain in the longitudinal space (meaning I don't have to query outside of in order to get results for geometries that were indexed with longitudes that went beyond the space. an implementation in which I can index features with unwrapped geometries ![]() It sounds like you are moving toward the exact implementation that I would find desirable: In the generic sense, that could mean having to split a single geometry into N>=1 geometries that live in the longitudinal space (concave polygons could be tricky). That being said, it would be great if you somehow create a generic enough implementation such that you can handle any geometry that crosses the international date line. I allow the longitudinal values to "unwrap" so that there is no ambiguity in the Geometry. Given the location of the data, the LINESTRING or POLYGON geometries could cross the international date line and have longitudinal values that break out of the region. I will mention that in different parts of my code I am using LINESTRING geometries and in other parts of my code I am using POLYGONS (usually just a rectangle). You are correct in that I would expect LINESTRING (-200 50, -160 60) to be equivalent to two linestrings (-180 55, -160 60) (160 50 180 55). The second issue remains, but it might not be significant. To get around 1, we can transform all coordinates to have lon (by adding/subtracting 360 until they are within the interval - not ![]() Greater than 180 - you can get around this by adding waypoints. To define a shape with successive coordinates having lon difference Validation error attempting to unwrap if it also contains successiveĬoordinates with lon difference greater than 180.Ģ) Also, the way spatial4j assumes dateline wrapping make it impossible If I transform all coordinates from my test cases to have lon, spatial4j performs dateline wrapping as we expect with theġ) It will either crop geometries outside of lon or throw a I have figured out more about what spatial4j does. Re: International date line dilemma for non-point geometries, possible bug? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |