Say that we have the following polygon:
Now I'm looking for one of two results, where either problem will help me continue my current tasks. So I would just need one of the following two problems to be solved:
Calculate the center line of the polygon:
Now I have looked at this post already, however the library used is outdated and I haven't managed to make it work properly.
Split the polygon into separate rectangles that fill up the entire polygon, non-overlapping.
Note that this is a very simple example of the kind of polygon whose solution I would need. I would need the exact same for a much more complex polygon, say the following:
So as I said, I need one of these 2 problems solved. Problem 1 is just a way to generate a solution for problem 2. Having the polygon split into distinct rectangles is the final goal.
Are there any resources that could help with this?
(Also pardon my paint-skills)
Well I am finding a way to generate points equally distanced from each other in an area (or a polygon)
I find a very useful source of doing it
https://mathematica.stackexchange.com/questions/141184/how-to-generate-approximately-equally-spaced-points-efficiently
https://newbedev.com/how-to-generate-approximately-equally-spaced-points-efficiently
However, I do not code C, I literally can not understand (or convert it to python code).
I am definitely not a math guy, just a problem while coding that I need to find a solution.
If you can find any sources or have codes that can perform it please share it to me.
I'm trying to build a simulation that will take place in a 1000x1000x1000 space. For each point in space, I need to be able to encode 2 or 3 properties.
I also need to be able to do some basic operations on the space, such as, given a point, find the properties of the 26 adjacent 3D neighbors of the point.
All points will lie on vertices in the 1000x1000x1000 space (i.e. every point is discrete).
I wrote up a version in python using numpy and it is much too slow. I've also looked for libraries that would speed it up but couldn't find anything.
Does anyone know of a python library that would provide useful helper functions and would be appropriate for a simulation of this size?
Using Numpy to together with the Numba python-compiler for the more intricate algorithms can take you a long way.
Also, I think you are refering to a "stencil" algorithm, and numba has specific stencil-functionality that could help you.
But start with a smaller grid during development!
I'm writing a program in Python. I have a series of shapes (polygons, defined as a sequence of coordinate pairs) and I need to tell if they overlap a particular rectangle.
Is there an easy algorithm for handling this? Or, better, is there a pure Python library that can handle these calculations for me?
Presuming your "arbitrary shapes" are indeed polygons (given that they're described as coordinate pairs), determining if they overlap (in any language) is a relatively trivial calculation. You merely need to compute if any side of polygon A intersects any other side of polygon B.
If you need an example, there's a rather thorough walkthrough at the Drexel Math Forum.
There are a number of Python modules which can assist you in this pursuit, such as Sympy, Numpy, PyGame, etc., but all of them are rather heavy if this is the only geometric calculation you need to make.
How do I calculate distance between 2 coordinates by sea? I also want to be able to draw a route between the two coordinates.
Only solution I found so far is to split a map into pixels, identify each pixel as LAND or SEA and then try to find the path using A* algorithm. Then transform pixels to relative coordinates.
There are some software packages I could buy but none have online extensions. A service that calculates distances between sea ports and plots the path on a map is searates.com
Beware of the fact that maps can distort distances. For example, in a Mercator projections segments far away from the equator represent less actual distance than segments near the equator of equal length. If you just assign uniform cost to your pixels/squares/etc, you will end up with non-optimal routing and erroneous distance calculations.
If you project a grid on your map (pixels being just one particular grid out of many possible ones) and search for the optimal path using A*, all you need to do to get the search algorithm to behave properly is set the edge weight according to the real distance along the surface of the sphere (earth) and not the distance on the map.
Beware that simply saying "sea or not-sea" is not enough to determine navigability. There are also issues of depth, traffic routing (e.g. shipping traffic thought the English Channel is split into lanes) and political considerations (territorial waters etc). You also want to add routes manually for channels that are too small to show up on the map (Panama, Suez) and adjust their cost to cover for any overhead incurred.
Pretty much you'll need to split the sea into pixels and do something like A*. You could optimize it a bit by coalescing contiguous pixels into larger areas, but if you keep everything squares it'll probably make the search easier. The search would no longer be Manhattan-style, but if you had large enough squares, the additional connection decision time would be more than made up for.
Alternatively, you could iteratively "grow" polygons from all of your ports, building up convex polygons (so that any point within the polygon is reachable from any other without going outside, you want to avoid the PacMan shape, for instance), although this is a refinement/complication/optimization of the "squares" approach I first mentioned. The key is that you know once you're in an area that you can get to anywhere else in that area.
I don't know if this helps, sorry. It's been a long day. Good luck, though. It sounds like a fun problem!
Edit: Forgot to mention, you could also preprocess your area into a quadtree. That is, take your entire map and split it in half vertically and horizontally (you don't need to do both splits at the same time, and if you want to spend some time making "better" splits, you can do that later), and do that recursively until each node is entirely land or sea. From this you can trivially make a network of connections (just connect neighboring leaves), and the A* should be easy enough to implement from there. This'll probably be the easiest way to implement my first suggestion anyway. :)
I reached a satisfactory solution. It is along the lines of what you suggested and what I had in mind initially but it took me a while to figure out the software and GIS concepts, I am a GIS newbie. If someone bumps into something similar again here's my setup: PostGIS for PostgreSQL, maps from Natural Earth, GIS editing software qGis and OpenJUmp, routing algorithms pgRouting.
The Natural Earth maps needed some processing to be useful, I joined the marine polys and the rivers to be able to get some accurate paths to the most inland points. Then I used the 1 degree graticules to get paths from one continent to another (I need to find a more elegant solution than this because some paths look like chess cubes). All these operations can be done from command line by using PostGIS, I found it easier to use the desktop software (next, next). An alternative to Natural Earth maps might be the OpenStreetMap but the planet.osm dump is aroung 200Gb and that discouraged me.
I think this setup also solves the distance accuracy problem, PostGIS takes into account the Earth's actual form and distances should be pretty accurate.
I still need to do some testing and fine tunings but I can say it can calculate and draw a route from any 2 points on the world's coastlines (no small isolated islands yet) and display the routing points names (channels, seas, rivers, oceans).