As populations grow and cities become more and more vertical, it is becoming increasingly vital to plan, manage, and analyze our urban environments in three dimensions. The purpose of the 3D Virtual City Special Interest Group (SIG) session is to give details on the current best practices and provide a forum for collecting future priorities for ESRI in this area. The 3D Virtual City SIG is for anyone interested in modeling, analyzing and maintaining an urban environment in 3D.
Join us on Tuesday 24th, from 12:00PM til 1:00PM in room 30 B
Gert van Maren
Product Manager 3D
What is this product? CityEngine 2012?
From road network and textures on the buildings, it seems that snapshot is from CityEngine.
On our practice, even though we have already produced several 3D globe services covering urban buildings, utilities and an open pit mine, all those feature classes don’t have any textures because 10.1 still doesn’t handle spatial reference ‘properly’ during Import *.DAE models.
Hopefully, 3D Virtual City SIG meeting can give more advices on this matter.
Larry Zhang
Saudi Aramco
3D plug-in for web applications:
Currently, 3D globe service(s), which are cached (served from ‘multipatch’ feature classes), are already available to all our ‘authorized’ users. As data and service provider, we are also confirmed that all above 3G globe services work fine in desktop ArcGlobe and ArcGIS Explorer (1750, 2012).
Also, image services from Mosaic Datasets (including DEM), and map services from cache directory are also accessible to our ‘authorized’ customers.
However, on high demands, GIS users and programmers also wants to consume those 3D globe service(s) inside ‘web’ applications. In other word, is there any 3D globe control (API) and 3D web viewer plug-in from ESRI available to programmers and web viewers? Any 3rd party plug-in available?
Not properly Import 3D model (*.DAE)
With 10.1, 3D model (*.DAE) can be successfully imported into feature class with textures, but is not able to add into ArcGlobe because the spatial reference (geodetic /WGS 1984 or web Mercator ) is not recoginized or defined during import.
If manually defining this multipatch within ArcCatalog, it is put in wrong place! Most likely, the bug is there.
thanks….