I'm brand new to openlayers, I've just been reading the docs today since I have a need to do some testing with it. I'd like to know if there's a way in openlayers to restrict the maximum geographic extent in a WMS tile request.
I've read that WMS bounding boxes are generated automagically, which is neat - but I have some issues with WMS requests on very large datasets which tend to make the underlying WMS server struggle. That's not really change-able, so we need to work around it, and one strategy is to request only small subsets at a time (~5 or 10 degree squares at most).
So - is there a way in openlayers to say 'get me at most 5 degrees by 5 degrees in a single WMS request, and build my map layer from those'?
Thanks in advance
Yes, you can set extent for your layer in such way:
new ol.layer.Tile( {
extent: ol.proj.transformExtent([30, 30, 50, 50], "EPSG:4326", "EPSG:3857"),
// your WMS source and other code
Please, make sure to use right projection. Example was given in case your map is in web mercator.
Related
Does anyone have suggestions regarding APIs available (free and paid) for posting a lat/long and the API returning a geoJSON shape file built from the lat/long posted?
For example, if I want to a shapefile of a 50 meter circle, derived from a lat/long 42.38567/-86.26877 CenterPoint, are there APIs that can do that? I have 24,000 locations I need this for, and I would very much like not to hand draw 24K polygons on a map.
I've investigated turf.js and developer.here.com but the documentation has been pretty unclear on what endpoint to post to, to solve this problem.
Most geographical libraries have buffer method, meaning they can do it locally (you don't even need any external API).
E.g. geopandas has buffer(distance, resolution) method - distance controls the radius, and resolution tells how precise the circle has to be. You construct point, call buffer method - get circle (approximated as polygon) as output.
Or you can load these points to a database with geospatial functionality (say, PostgreSQL + PostGIS) and call ST_Buffer method to do the same.
Is there anyway to specify a (Tile)WMS source that supports multiple projections?
For example, my WMS server supports requests for both EPSG:4326 and EPSG:3395. So if the projection is supported in server-side, the tiles are requested with the appropriate projection, else OpenLayers tries to reproject one of the supported projections.
You can use the client side reprojection to do that, see this example .
Just add a projection property to your ol.source.TileWms.
UPDATE: The basic question is, if my GeoJSON delivered by the REST interface (Json data is visible at end of question) is a valid GeoJSON for the vector layer, because as soon as i add this as source for the vector layer, the layer is broken.
Currently there is no REST Interface to upload shapes, so i just took some valid coordinates from current shapes and created a static JSON on serverside
I try to make it possible that users can draw shapes (Polygons, Lines) on a vector layer and the i store the geometric data on a server and the next time the map is loaded it should be displayed again. But it seems somehow when i define my REST interface as source for the vector layer, that there is some problem as painting and adding objects into the vector layer does not work anymore.
Here the code i put together from OpenLayers Examples. First an image how it should look like:
I extracted the coordinates on the map with drawend event and built a REST interface where i could load the geometric data, this is the response i get for the vector layer source:
{
"type":"FeatureCollection",
"crs":{
"type":"name",
"properties":{
"name":"EPSG:2000"
}
},
"features":[
{
"type":"Feature",
"id":"1",
"properties":{
"name":"TEST1"
},
"geometry":{
"type":"LineString",
"coordinates":[
[
-5920506.46285661,
1533632.5355137766
],
[
-1882185.384494179,
234814.55089206155
]
]
}
}
]
}
But if i load this, nothing will be displayed and its not possible to draw on the layer anymore (if i remove the "source" attribute from the vector layer source it works again)
Here the complete code on pastebin: Example Code
I fixed the problem meanwhile, i was trying to load GeoJSON into my vector layer but the vector layer was always broken afterwards. As i was pretty new to open layers, i didn't notice my mistake, but i had syntax errors in my GeoJSON and the coordinates i supplied were also wrong.
After correcting the syntax and the coordinates everything is working as intended and as mentioned above EPSG:3857 was also the right thing to use. Sorry for my first messy experiences with open layers, but thanks for the friendly help ;)
I'm attempting to stream Tweets from the UK as a whole, using Twitters stream API, however I'm having trouble with my bounding box.
The LAT/LON pairs I'm using to define a bounding box of the whoe UK(Ire included) is as follows.
-9.05, 48.77, 2.19, 58.88
However when I try to use this with the Twitter stream API, it states the following error message.
Location track must be less than 1 degrees on a side: LocationTrack(48.77,-9.05,58.88,2.19)
I can't imagine that Twitter do not allow you a specify a bounding box that covers an area that crosses between the negative/positive LAT. Am I missing something here, or would this mean that Twitter only allow you to stream if you are in the Wester hemishphere, effectively?
If anyone has a suggest as to how I might be able to over-come this, I'd be very interested in hearing you out.
The reason for this is ambiguity around the meaning of the word 'degree' in this error.
Due to the lat/lon coordinates being used, I assumed it meant the actual VALUE of the degree in the second lat/lon pair, where as in actual fact it means the SIZE of the bounding box.
My bad.
I am developing a game for the web. The map of this game will be a minimum of 2000km by 2000km. I want to be able to encode elevation and terrain type at some level of granularity - 100m X 100m for example.
For a 2000km by 2000km map storing this information in 100m2 buckets would mean 20000 by 20000 elements or a total of 400,000,000 records in a database.
Is there some other way of storing this type of information?
MORE INFORMATION
The map itself will not ever be displayed in its entirety. Units will be moved on the map in a turn based fashion and the players will get feedback on where they are located and what the local area looks like. Terrain will dictate speed and prohibition of movement.
I guess I am trying to say that the map will be used for the game and not necessarily for a graphical or display purposes.
It depends on how you want to generate your terrain.
For example, you could procedurally generate it all (using interpolation of a low resolution terrain/height map - stored as two "bitmaps" - with random interpolation seeded from the xy coords to ensure that terrain didn't morph), and use minimal storage.
If you wanted areas of terrain that were completely defined, you could store these separately and use them where appropriate, randomly generating the rest.)
If you want completely defined terrain, then you're going to need to look into some kind of compression/streaming technique to only pull terrain you are currently interested in.
I would treat it differently, by separating terrain type and elevation.
Terrain type, I assume, does not change as rapidly as elevation - there are probably sectors of the same type of terrain that stretch over much longer than the lowest level of granularity. I would map those sectors into database records or some kind of hash table, depending on performance, memory and other requirements.
Elevation I would assume is semi-contiuous, as it changes gradually for the most part. I would try to map the values into set of continuous functions (different sets between parts that are not continues, as in sudden change in elevation). For any set of coordinates for which the terrain is the same elevation or can be described by a simple function, you just need to define the range this function covers. This should reduce much the amount of information you need to record to describe the elevation at each point in the terrain.
So basically I would break down the map into different sectors which compose of (x,y) ranges, once for terrain type and once for terrain elevation, and build a hash table for each which can return the appropriate value as needed.
If you want the kind of granularity that you are looking for, then there is no obvious way of doing it.
You could try a 2-dimensional wavelet transform, but that's pretty complex. Something like a Fourier transform would do quite nicely. Plus, you probably wouldn't go about storing the terrain with a one-record-per-piece-of-land way; it makes more sense to have some sort of database field which can store an encoded matrix.
I think the usual solution is to break your domain up into "tiles" of manageable sizes. You'll have to add a little bit of logic to load the appropriate tiles at any given time, but not too bad.
You shouldn't need to access all that info at once--even if each 100m2 bucket occupied a single pixel on the screen, no screen I know of could show 20k x 20k pixels at once.
Also, I wouldn't use a database--look into height mapping--effectively using a black & white image whose pixel values represent heights.
Good luck!
That will be awfully lot of information no matter which way you look at it. 400,000,000 grid cells will take their toll.
I see two ways of going around this. Firstly, since it is a web-based game, you might be able to get a server with a decently sized HDD and store the 400M records in it just as you would normally. Or more likely create some sort of your own storage mechanism for efficiency. Then you would only have to devise a way to access the data efficiently, which could be done by taking into account the fact that you doubtfully will need to use it all at once. ;)
The other way would be some kind of compression. You have to be careful with this though. Most out-of-the-box compression algorithms won't allow you to decompress an arbitrary location in the stream. Perhaps your terrain data has some patterns in it you can use? I doubt it will be completely random. More likely I predict large areas with the same data. Perhaps those can be encoded as such?