I am looking for a way to implement that QGIS Filter to smooth agriculture zones within a field. Right now I have many artifacts. I want to smooth and eliminate artifacts smaller than specified number of pixels and instead pick neighboring max.
I tried using ndimage.grey_dilation and got an acceptable result, but still have artifacts at then end (that I'd like to remove without re-running through a new dilation).
The mentioned QGIS filter seems to do something better.
Just curious. I know it is called morphological opening, but results are not awesome.
See below:
Related
TL;DR: can anyone help w/ geospatial things in R using geom_raster() in ggplot?
Basically it seems that my issue is stemming from the fact that I don't have perfectly gridded values (aka I get this message: "Warning: Raster pixels are placed at uneven vertical/horizontal intervals and will be shifted. Consider using geom_tile() instead."). So, if I switch to geom_tile, then I can control the size of the tiles, but then they look chunky and awful since there's no interpolation feature in geom_tile. If I use geom_raster, I think it gets confused what size it should plot the pixels since it's not perfectly gridded, so when I facet my ggplot, the output sometimes will have teeny tiny dots (or even no dots at all) on some facets, and pretty maps on the other facets. When I round the lat/lon coordinates to 0 decimal places, this fixes the teeny tiny / no dots problem, but then ends up with things just like geom_tile (chunky with no blending between).Any ideas on how to fix this? I think if there's a way to manually interpolate to fill in NA values so that I do have nice symmetrically-gridded data, then geom_raster should work fine. Like what needs to happen is for each situation where we're missing a value at a certain lat/lon, we need to take the mean value between the two closest neighboring points to fill in that missing lat/lon point on the grid. But I'm not sure how to do this (aka how to convert from my dataframe into all the different spatial classes and back again). Then again, this manual approach might be overcomplicating things and I'd love a simpler solution. (fingers crossed)
I'm building this in a shiny app with crazy long code, and a very large dataset, but happy to share additional info as needed!
example plot
example plot2
warning example
How to have continuous features for a shapefile ?
I mean NOT cut by the dateline to respect [-180:180] longitude excursion that I do not
want to respect.
Here is an example where I display the Russia shapefile in a leaflet map.
In fact I would like to have continuous continent.
Shapefile comes from
https://gadm.org/about.html
Any command from gdal or ogr2ogr to merge separated features ?
Thanks
If you load the GADM level-0 layer into QGIS and toggle Show Feature Count, you'll see that, even though the shape seems split, the actual layer only has a single feature:
Your shape gets cut off because the polygon crosses the boundary in the projection you are using and gets wrapped around. This doesn't mean the features get actually split.
If you want to display it as a continuous feature, you need to specify an appropriate projection. For instance, using the example here gives me this:
This is just one way, there might be different projections that fit your purpose better. Also, getting this done in leaflet is a different question.
I use components with significant size for vertices (by overriding mxGraphComponent.createComponents), and using mxOrganicLayout or mxFastOrganicLayout makes them overlap. mxHierarchicalLayout doesn't with my current graphs, but I am not sure whether this is guaranteed.
Can I 1) avoid overlap in either of organic layouts? 2) be sure that mxHierarchicalLayout nodes will never overlap?
Not sure if you're still looking for a solution here, but I found your question when trying to avoid overlap myself.
In case you didn't know, you can experiment with some of the attributes for the organic layouts. For example, you can do the following:
mxFastOrganicLayout layout = new mxFastOrganicLayout(adapter);
layout.setForceConstant(150);
The force constant has the following description in the docs:
The force constant by which the attractive forces are divided and the replusive forces are multiple by the square of.
For me, I played around with the force constant until I got a layout with far fewer overlaps. There are a number of other attributes that you can play around with as well to see if this helps your overlapping issues. The ones that made the most difference for me are as follows:
layout.setMinDistanceLimit(5);
Increasing your minDistanceLimit should allow your vertices to spread out more.
Since fastOrganicLayout also works through simulated annealing, you can actually specify the maximum amount of iterations to run the layout through. If your map is particularly complex (with lots of vertices) it might also help to increase this.
layout.getMaxIterations(2000);
For me, changing the force constant made the most difference but your mileage may vary.
I've not used hierarchical layout before but there seem to be similar attributes that you can change which may lessen your chance of overlap.
If you came up with a more solid solution than this then it would be great if you could share it.
I am working on a game which was developed by some other guy earlier. I am facing a problem that when player(with camera) start running on the road the buildings are not being shown up in their regular shape and as we move forward (more closer to the buildings) they gain their original shapes, and some times the buildings present on either side of the road are not visible by camera ( empty space ) and when we move closer to the building it comes up as visible object suddenly. I think it may be some unity3d setting problem (rendering , camera or quality). May be, it was being done due to increase performance on mobile devices.
can anybody know what may be the issue or how to resolve it.
Any help will be appreciated. Thanks in advance
This sounds like it's a problem with the available LODs for each building's 3D model.
Basically, 3d games work by having 2-3 different versions of each 3D model, with varying *L*evels *O*f *D*etail. So for example, if you have a house model which uses 500 polygons, you'll probably have another 2 versions (eg 250 polys and 100 polys), which are used depending on the distance between the player and the object. The farther away he is, the simpler the version used will be.
The issue occurs when developers use automatically generated LOD models, which will look distorted or won't appear at all. Unity probably auto generates them, but I'm unsure where you'll find the settings for this in unity. However I've seen 3d models on the unity store offering models with different LODs, so unity probably gives you the option to set your own. The simplest solution would be to increase the distance the LODs change at, while the complicated solution would be to fix custom versions of the 3D models for larger distances, with a lower poly count.
I have resolved the problem. This was due to the LOD (level of details) used for objects (buildings) in Unity3d to enhance the performance on the slower device. LOD provides many level of details (of an object) which you can adjust according to your need . In my specific problem the buildings were suddenly appear due to the different (wrong) position for LOD1, i.e. for LOD1 the building was at wrong place but for LOD0 it was at its right place. So when my camera see from the distance it see LOD1 which was at wrong place thence it sees empty space with no building at the expected position. But when camera comes closer it sees LOD0 in which building is at the right position and it seems that buildings are suddenly come or become visible.
I'm using Foursquare API to get a list of venues of a certain category.
One important requirement is that the list is exhaustive, i.e. includes all relevant points. The v2/venues/search API endpoint enforces a limit of 50 venues on the output.
So the first idea that comes to mind is splitting the area into several sections (using "sw" and "ne" params) and then combining the results.
Clearly, the density of points will vary dramatically depending on location, so we'll need to use some kind of adaptive algorithm to flexibly adjust the size of the search window so that it contains all points. Also, there's an increased risk of running into the rate limit, so we might need the algorithm to stop when it's used up its quota of requests.
Finally, it seems that the only way to tell if a search window should be shrunk even further is to count the number of points in the result: if we have less than 50, then we've got a complete list for this section and can move on to the next one; otherwise, we should split it further. It seems to be wasteful as we'll be throwing away the intermediate results (i.e. all results in our search tree except for the leaves).
So here are some questions that I have:
Is it the best way to put together an exhaustive list? Maybe I'm
missing some API functionality?
Is there any specific algorithm you'd use in this case?
How would you go about reducing the number of results that have to be thrown away?
Thanks in advance!
An important disclaimer would be that foursquare does not like it when you perform a lot of searches in the same area.
Having said that, you should look into experimenting with categoryId filter in the venue search api. Most of the data on foursquare is food (restaurants) and nightlife related.
So if you exclude these (by including others, no way to exclude) you can search on a larger area and still get below 50 results.
Never really tried using such an algorithm because the categoryId filtering worked good enough, but in theory, the algorithm is simple, each lat/lng 0.001 is ~111 meters.
Search using a small radius (~200 for large metropolitan areas) and triangulate (scan) areas.
What got us to originally perform a lot of searches (and later stop doing so) is that sometimes foursquare filter out results without asking you (for me, it looks like bugs, for them its part of the algorithm). So for example I would search on a 50 meter radius, find the place I want (I know what I am searching for), expand to 500 meters, not find it (and get less than 50 results - so it was not dropped out because I hit the cap, it was dropped out because ???), move my search location ~300 meters north, find it -> sporadic behavior.
My point is (and the reason for why we stopped making a lot of searches and changed our approach), what you are trying to achieve, 'complete coverage' is very hard to do given the current API and the current usage policy, and -> it is not important really. After a few months of playing with it, we figured out that we should query foursqaure for what our users are looking for and require at this moment, we cache the results - over time we will have a complete coverage, maybe at start we will miss a few spots, but for the long run its not really important.
Hopefully this is not what you're doing, but as a friendly reminder: scraping foursquare's website and/or API is very much prohibited by its terms of service.