Some fun with terrain data

So I needed something fun to do for a Monday afternoon, so here’s a 10km square of the Grand Canyon as gathered from the United States Geographical Survey :slight_smile:



I have a pretty good idea of the first direction I’m going to go with this, but will play that close to the vest until its super cool to show off!



2 Likes

I should probably mention that I have since shared this on SourceForge: CanyonJam

so what does canyonjam? what is it based on?

sbook: that’s great - including real data will bring lots of new opportunities.



Would you mind passing on how you converted the data?



Did you convert it to a JMonkeyEngine friendly format, or just treat it as a 2-d array of heights?

In case @sbook (refer to the member with the @ in front to give that user a message about your post) won’t respond in a while. HeightMaps for terrains in jme3 are given as float arrays (ref. constructor in TerrainQuad

[java]public TerrainQuad(String name, int patchSize, int totalSize, float[] heightMap))[/java]

So reading and converting a heigtmap file (e.g. DEM formated file from the SRTM) to a float array is one way to do the above.



So for accessing an element located at (x,z) you could use the following method:

[java]

public float getHeightmapHeight(float x, float z, float heightmap[]) {

if (x < 0 || z < 0 || x >= size || z >= size)

return 0;

int idx = (int) (z * size + x);

return heightmap[idx]

}

[/java]

hey, thanks @makeshift :wink:



I guess I was fishing to see if he had some kind of library which took on some of the grunt-work - such as provide the library with a DEM file/files and let the lib extract the float[] array for selected regions. Such a lib could then have backend support for other gridded elevation sets.



But, I suspect you’re observation is correct - he probably did that grunt-work using one-off custom code.



cheers,

Ian

Should be really easy, just google around for DEM reading/conversion or something.

The link i provided also gives an explanation of the DEM standard.

thanks for coming back so promptly @makeshift



You’re right that it would be easy - the code’s all there in GeoTools. I would only want to create my own code as a last resort - even if I was actually pulling in GeoTools to do the leg work. My ‘first-resort’ is to see if there’s already support in the JMonkeyEngine ecosystem - and see if I can improve/extend this. It does appear this doesn’t exist - but I guess it’s worth waiting for a couple of days to see if sbook does chip in with any updated guidance.



cheers,

Ian

but I guess it’s worth waiting for a couple of days to see if sbook does chip in with any updated guidance.
I agree :)

Hi all, thanks for putting the @ in there! It looks like I wasn’t getting email from older topics :frowning:



@ianmayo, it was one-off code at the time that I had made to function as a sort of musical synthesizer based on the height below your location, but was supposed to end up integrated into the Betaville project. Its in there now and is used in conjunction with OpenStreetMap data.



As far as one-off custom code, there’s some abstraction done above the level of jME2 terrain creation, but you should be able to swap TerrainQuads right in there where TerrainBlock is used. As for creating this, we use real-world location coordinates to trigger the building of these objects.



If you get the Betaville source code, there is “ILocation”, which is a pretty straightforward interface for locations around Earth. There are two very simple implementations, GPSCoordinate (for the WGS-84 styled latitude/longitude system you’re likely familiar with) and UTMCoordinate (which is based on the Universal Transverse Mercator system). If you’re a bit more comfortable with GIS data, there is also a wrapper implementation for EPSG projections that converts them into one of the aforementioned WGS or UTM systems for you.



The data used there is coming from USGS queries performed and parsed with this code: http://code.google.com/p/betaville/source/browse/BetavilleApp/trunk/src/edu/poly/bxmc/betaville/xml/USGSResponse.java



We also have the NASA ASTER data set that came off a joint mission with Japan (iirc, their government’s economic body). The resolution on it is far better than DEM and SRTM data and has pretty good quality control included. The only problem is that the set is 125GB compressed and inflates to about 5x that size… One of these days I’ll get around to writing utility that pushes all of the data into MySQL or Postgres… The other nice thing, besides the resolution, is that it covers most of the Earth’s land mass, while the USGS data is only good for CONUS

I hate double posting, but I missed some posts while I was writing that up :x



@makeshift, working with DEM is a total pain… those links you provided link to over 300 pages of documentation, where you actually need to read a ton of it because its a binary format and you can’t really take guesses as with a plain-text format… And GeoTools already has DEM functionality I believe, so there’s really no reason to put yourself through that :stuck_out_tongue:

Hi there @sbook thanks for the thorough reply(s)



By the way, do you think there’s mileage in developing a wrapper so JMonkeyEngine could be a GeoTools renderer? Or, conversely, for GeoTools to be a backend terrain data-provider for JMonkeyEngine?



In this way one lib would plug-in to the other, rather than users hand-crafting the integration themselves. Once the API is crafted alternative implementations could be dropped in as required.



just a thought…

Yep, absolutely! That’s been my day job since the beginning of 2009 :slight_smile:



The only things I use GeoTools for are for its ability to handle different projections (EPSG codes, WKT, etc), the MathTransforms between them, and its GeoTIFF functionality (which is the format of the ASTER data).



You have to be careful with your math, as most of GT (and other precision libraries) favor double precision, while graphics engines tend to go with float. If you take a look at the Betaville MapManager class (I have an implementation for jME3 that I should make public), it will translate an ILocation into a point within the 3D scenegraph. The only real magic here is that you can calibrate it based on your position… so a normal procedere might look like:



Calibrate to new york

Put stuff somewhere

Move the camera to a point

Put stuff somewhere

Calibrate to Berlin

Re-align old contents

Put stuff somewhere

Move the camera to a point

Put stuff somewhere

@sbook said:
@makeshift, working with DEM is a total pain.. those links you provided link to over 300 pages of documentation, where you actually need to read a ton of it because its a binary format and you can't really take guesses as with a plain-text format.. And GeoTools already has DEM functionality I believe, so there's really no reason to put yourself through that :p

Nice you could provide a better answer than mine. I had no idea, I guessed DEM was basically just a list of numbers :p I only provided the links since I've come across them earlier while playing around with DEM files, using software to process them.
http://code.google.com/p/betaville/source/browse/BetavilleApp/trunk/src/edu/poly/bxmc/betaville/xml/USGSResponse.java
Looks cool :)
makeshift said:
Nice you could provide a better answer than mine. I had no idea, I guessed DEM was basically just a list of numbers :p I only provided the links since I've come across them earlier while playing around with DEM files, using software to process them.


There's also the quality control documentation for it, which you need to take into account when processing it (if you're writing the processor yourself, of course). It turns into a pretty confusing exercise at some point when you're staring at a huge whiteboard trying to remember why you're doing it in the first place -_-

makeshift said:
http://code.google.com/p/betaville/source/browse/BetavilleApp/trunk/src/edu/poly/bxmc/betaville/xml/USGSResponse.java
Looks cool :)


For all the coolness in there, you have to really hand it to the USGS! They're without a doubt my favorite science agency and seem to have people sprinkled all over that are really passionate about science... I always love interacting with anything they provide :)