[x3d-public] Showcase: 3D maps showing sea level change using X3D/X3DOM

Mon Feb 25 12:17:31 PST 2019

Hello Andreas,

That's a great compilation and overview of sea level change and its effects! Your full Earth 3D scene is really striking. I made my views in pieces because I wanted to use the full resolution of the GEBCO half minute grid dataset, hence the at first glance somewhat odd size and scale, with 667 km in 720 pixels/vertices vertically, but that's just 6° = 360' = 720 x 0.5'. Even if I'd love to make a complete overview like yours, I doubt many desktop computers would swallow 933,120,000 (360 x 120 x 180 x 120) vertices with coordinates, normals and colors and be able to render the resulting 1,866,240,000 tris it in somewhat smooth animation. It might be possible with LOD models, but I haven't gotten that far yet.

X3DOM is a really nifty web integration tool, and together with X3D so far the simplest way I've found of integrating 3D content on web pages. As I learn more, I can see that it's more capable than I thought at first, but then the learning curve also turns upwards steeply. It still has some way to go before it could become a generally acceptable standard for industry though. I was involved in a project a few years back where various 3D platforms were evaluated for a major investment, and what tripped most of them were lack of stable (meaning more than a few developers involved) and secure (meaning extensive test suites and quality management) development, and deficits in documentation, rather than their actual capabilities. Unfortunately, that's a problem with most opensource projects I've been involved in or in touch with.

Best regards,

Magnus Zeisig

> 25 feb. 2019 kl. 16:48 skrev Andreas Plesch <andreasplesch at gmail.com>:
> 
> Thanks for sharing a nice use case for X3D on the web.
> 
> For a past global sea-level change demonstration I used a much subsampled DEM for a GeoElevationgrid in geodetic coordinates and a transparent, constant heights, GeoElevationgrid with matching gridding for the sea-level. The height attribute value can be dynamically modified using a slider and a bit of JavaScript via the DOM.
> 
> The yScale field is reserved for vertical exaggeration for both grids which is helpful for visualization of large areas or the globe. It is dynamic as well.
> 
> GeoElevationgrid is really useful for such global or continent scale datasets along with the other geospatial nodes since the distortions of map projections can be sidestepped this way.
> 
> The geospatial nodes are also useful for direct consumption of lat.long. located data, or if the effect of the Earth's curvature is considered important for the scene.
> 
> Here is a prototype of such a X3D scene:
> 
> https://beta.observablehq.com/@andreasplesch/sea-level-past-present-and-future <https://beta.observablehq.com/@andreasplesch/sea-level-past-present-and-future>
> 
> It uses a new approach to notebooks and was initially a test of how well x3dom fits in such a notebook environment. But it could be just as well a regular web page.
> 
> Apart from being a X3D browser, x3dom is geared towards integration into the web. Generally, web technologies work well with it. 
> 
> Andreas
> 
> On Fri, Feb 22, 2019, 10:37 PM <x3d-public-request at web3d.org <mailto:x3d-public-request at web3d.org> wrote:
> 
> Date: Thu, 21 Feb 2019 21:12:50 -0700
> From: GPU Group <gpugroup at gmail.com <mailto:gpugroup at gmail.com>>
> To: Magnus Zeisig <magnus.zeisig at tele2.se <mailto:magnus.zeisig at tele2.se>>
> 
> Magnus, I think your spherical world with overlapping rectangles and
> anchors is great - a great way to do it.
> -Doug
> 
> more on geospatial..
> 
> The web3d geospatial has 3 options for coordinate systems:
> 1. GC geocentric
> 2. GD geodetic or lat,long
> 3. UTM
> I'm not sure if/how a GeoElelvationGrid would work with GC.
> GD and UTM get a little funny around the poles. But lets say you use one of
> these. Then for sea level you set heights to 1, and yscale to 0, to get
> 0=sea_level and scale by 10 to get 10.
> Q. when you say you did them on a plane, do you mean mapping plane, and if
> so what type of mapping plane ie UTM, stereographic, lambertian conic ...?
> One idea is expand the number of mapping planes offered in the geospatial
> component, so if you have a nice grid in some non-utm mapping plane, you
> don't have to regrid to utm or lat,long.
> 
> On Thu, Feb 21, 2019 at 11:39 AM Magnus Zeisig <magnus.zeisig at tele2.se <mailto:magnus.zeisig at tele2.se>>
> wrote:
> 
> > Thank you for the feedback, Doug.
> >
> > When I produced the 3D scenes in question, I hadn't gotten into the
> > geonodes yet, put dealt with them as general 3D scenes. Since they aim for
> > compatibility with a set of videos produced in the plane projection, I
> > probably would have decided to use that projection, at least for one
> > version, even if I had been familliar with the geonodes.
> >
> > If I was to use GeoElevationGrid, would it work to add sea level as a
> > second GeoElevationGrid with some blue tint and all height values set to 0,
> > and then scale it with a transform where scale is set to
> > [1+SeaLevel/EarthRadiusEquator, 1+SeaLevel/EarthRadiusPoles,
> > 1+SeaLevel/EarthRadiusEquator], if using the ellipsoid approximation? If it
> > works the way I think, even using the geoid should be OK, since its
> > variation is only up to 106 m from the ellipsoid, giving an error of up to
> > 106/6371000*65?0.001 m at the maximum realistic sea level rise of 65 m. I'm
> > not sure what internal mathematical resolution is used though, since a 1 m
> > sea level rise would mean a scale factor of just about 1.00000016, which
> > would be problematic with single-precision floats.
> >
> > If I understand your suggestion about linking from a geo world right, I
> > think I did something like that already, although "cheating" just using a
> > textured sphere and scaled boxes as scene markers:
> > http://sealevelrise.se/en/earth_3d1/map1.html <http://sealevelrise.se/en/earth_3d1/map1.html> . The overlapping
> > semi-transparents mess up some, as with many 3D tools, but the anchor
> > principle works and I think should work also with more complex solutions.
> >
> > I admit several of your other questions/suggestions are shooting a bit
> > over my head, since I'm no expert in GIS/geodata/geospatial handling, but I
> > might get there with time.
> >
> > Best regards,
> >
> > Magnus
> >
> >
> > 21 feb. 2019 kl. 17:04 skrev GPU Group <gpugroup at gmail.com <mailto:gpugroup at gmail.com>>:
> >
> > I think its awkward and some things are missing from x3d geo nodes.
> > Lets say you have an elevationgrid in an arbitrary mapping plane, with
> > respect to geoid ie heights measured from sea level.
> > There's no node that will take that grid as it is and display it on a
> > spherical earth with the proper adjustments for curved ellipsoidal earth,
> > including geoid-to-ellipsoidal heights.
> > If it was a small grid, it could be positioned with a geoLocation node
> >
> > http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#GeoLocation <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#GeoLocation>
> > But what about large areas where an uncorrected grid would be obviously
> > wrong? Victoria Island in the Arctic Ocean for example?
> > A similar problem if you keep your elevationGrid and use a GeoTransform to
> > bring an ellipsoidal earth into your regular scene.
> >
> > You could convert all your grid points to GeoCentric GC coordinates
> > offline, and show it as mesh of points in GeoCentric coordinates. But that
> > makes it awkward / less sensitive to show sea level rise relative to geoid.
> > Normally we convert geoid heights to ellipsoidal heights to render in geo
> > space. So a (geoid following) sea would need to be a grid of points
> > following the geoid, and (somehow) mathematically scaled.
> >
> > Perhaps on your page listing all of the locations/areas-of-interest, that
> > could instead be on a geo world, and each area an approximate rectangle on
> > it, with TouchSensor/Anchor. Then when someone clicks on an area, you go to
> > your current elevation grid page? Would that work in x3dom?
> >
> > To do it all on one ellipsoid
> > A node type that will take your grid in sea-level/geoid relative mapping
> > plane coordinates which may not be UTM - may be some other mapping plane
> > especially near the poles- and do the appropriate conversion on each grid
> > point for rendering and collision/terrain-walking, and do that also with a
> > grid for sea level too, and provide a way to animate the sea level height
> > around the world and/or locally (animated geoid? Geoid as an exposed field?
> > geoid scale factor? special sea level node that includes tide modeling?)
> > ... that needs work.
> >
> > Doug Sanden
> >
> >
> >
> >
> > On Wed, Feb 20, 2019 at 4:16 PM Magnus Zeisig <magnus.zeisig at tele2.se <mailto:magnus.zeisig at tele2.se>>
> > wrote:
> >
> >> Hello Mike,
> >>
> >> Thank you for your positive feedback and for the tip about the
> >> GeoElevationGrid. I admit I hadn't gotten that far yet, but will definitely
> >> keep it in mind for future 3D mapping projects. For this particular project
> >> I probably would have decided to stick with the ElevationGrid even if I had
> >> known though, since I then more easily could match it to a set of "flat"
> >> videos of the same areas I had already produced and had much of the data
> >> conversion done already for that purpose.
> >>
> >> If I understand it right, the GeoElevationGrid can be used both for full
> >> sphere and partial sphere (if (xDimension - 1) * xSpacing < 360 or
> >> (zDimension - 1) * zSpacing < 180) topography, but will always result in a
> >> correct but sometimes impractical spherical projection, also more
> >> triangular (or really concentric circle sector) than rectangular towards
> >> the poles? Adding a sea level with adjustment should just be a matter of
> >> adding a corresponding second GeoElevationGrid with all height values 0 and
> >> scaling it by changing an enclosing Transform scale field?
> >>
> >> Best regards,
> >>
> >> Magnus
> >>
> >>
> >> > 20 feb. 2019 kl. 18:36 skrev Mike McCann <mccann at mbari.org <mailto:mccann at mbari.org>>:
> >> >
> >> > Hello Magnus,
> >> >
> >> > This is a very intuitive and informative interactive presentation!
> >> >
> >> > I agree that X3D/X3DOM is a smoother choice, especially when we have
> >> limited time and need to do a lot of data preparation.
> >> >
> >> > I notice that you use a single ElevationGrid and can understand why, as
> >> it?s simpler to integrate the Sea level adjustment component of your
> >> application.
> >> >
> >> > Just a note regarding dealing with geospatial data: X3DOM also has the
> >> Geospatial component ? if GeoElevationGrid were used then other data might
> >> be more easily added to the scene using latitude, longitude, elevation
> >> coordinates, rather than having to first convert to custom coordinates
> >> needed for each ElevationGrid.
> >> >
> >> > -Mike
> >> >
> >> >> On Feb 20, 2019, at 3:25 AM, Magnus Zeisig <magnus.zeisig at tele2.se <mailto:magnus.zeisig at tele2.se>>
> >> wrote:
> >> >>
> >> >> I just wanted to say thank you to the community and developers for
> >> providing a great, quick and simple tool to get 3D scenes done and
> >> published. It took me a week of spare time from completing the first
> >> "Hello, X3DOM!" tutorial to having a set of 370 coastal areas around the
> >> world in interactive 3D on the web, most of that time required to massage
> >> geodata from GEBCO and GeoNames into proper format:
> >> http://sealevelrise.se/en/earth_3d1/ <http://sealevelrise.se/en/earth_3d1/>
> >> >>
> >> >> At least initially looking more for a quick tool to get the job done
> >> than to really learn all the nuts and bolts of X3D and X3DOM, I've probably
> >> made a lot of beginners' mistakes, and I'm sure I'll revisit and improve
> >> the project as I learn more, but for now, it's up, working and looking
> >> good. Once more, thank you!
> >> >>
> >> >> As a background, I'm not all new to 3D. I wrote my first 2-pass (light
> >> and shadow) 3D renderer back in 1981, in BASIC on a micro-computer with a
> >> 2.2 MHz 8 bit Z80-processor and 32 KB RAM, taking 2 weeks to render a 332
> >> face mesh model (608 tris) in high resolution (2304x1152 px). In 1995-1996,
> >> I created my first 3D scenes on the web using VRML, and later worked with
> >> software like RayDream Studio, POV-Ray, Carrara and Poser. 2007-2008 I went
> >> into virtual worlds like Second Life and OpenSimulator, and contributed
> >> some code to OpenSimulator. Lately, I've created some 3D web content using
> >> WebGL and ThreeJS, and contributed some to the ThreeJS documentation.
> >> >>
> >> >> I left VRML when the existing viewers went defunct on Macintosh in the
> >> late 1990's, leaving it without a properly functioning viewer for a while,
> >> and since I didn't hear much about VRML afterwards, I assumed it more or
> >> less dead. I'm happy to see I was wrong and that its offspring X3D is still
> >> alive and kicking. While e.g. ThreeJS has its charm for some projects, it's
> >> overkill for others, and at least for this project, X3D/X3DOM definitely
> >> was a smoother choice.
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> x3d-public mailing list
> >> >> x3d-public at web3d.org <mailto:x3d-public at web3d.org>
> >> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
> >> >
> >> >
> >> > _______________________________________________
> >> > x3d-public mailing list
> >> > x3d-public at web3d.org <mailto:x3d-public at web3d.org>
> >> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
> >>
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org <mailto:x3d-public at web3d.org>
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190221/aacfb921/attachment-0001.html <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190221/aacfb921/attachment-0001.html>>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org <mailto:x3d-public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
> 
> 
> ------------------------------
> 
> End of x3d-public Digest, Vol 119, Issue 66
> *******************************************
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190225/7fe68926/attachment-0001.html>