converting KML to 3D, part 1

the pdf version can be found here

Ok, so let’s put everything together into a workflow. We are setting out to create a fast way of creating real 3D worlds in Flex that can be playable within browser with Flash Player installed. We found Google Earth application as the most suitable form of providing data for our system. We want the user to be able to create a city - preserving real world coordinates, distances and building sizes in the fastest possible way. As we speculated before on the data - using Google Earth gives users ability to create polygons (using real world satellite image as a drawing layer) for any, I say any city found on the Google Earth surface. It can be part of New York City as well as clay houses in Bamako in Mali. So in fact it doesn’t matter if user wants to create a small village or University Campus of big city, it will take him the same amount of time (to be more specific it can be less than 10minutes!!!, it only depends on precision that user wants to achieve). Then after the polygons (and additional data such as height of buildings, placemarks, etc. – see KML reference in Technology chapter) are created we save them into KML file. This is the fastest and most intuitive way for normal user I found to create user customizable world data. KML is also commonly used as well among web society for showing users positions on the world for instance (Google Maps). What is more the polygon coordinates are not the only information that can be stored inside KML file, so we have more options to discover and make investigation on later. So how we are going to view the data from a KML file into a browser playable swf file? First of all to start, we will need something like a KML class that will serve as file parser and provide us with math to calculate the world positions from Google earth. That class will need to be implemented in ActionScript so that we can use it within Flex application that will produce that swf file. If we connect those two, then we can attach PV3D engine to the application and try to view the data. At that point we should have a 3D displayable KML data using swf file. Next we can create navigational system based on First Person Perspective camera (or like Windows Live Maps - Birds eye) and attach more options from KML files and other techs (like support for Collada files or using Web Services for instance) to the whole system. Ok, so let’s set sail into some ActionScript coding.

Before writing some code let’s consider a structure that we would like to have and that would be most universal for further functionality/extensions. The KML file structure as described earlier holds a tag coordinates, which is the most interesting data for us at the moment. Finding and getting a coordinates tag should not be a problem using E4X API in ActionScript 3.0. However we must take under consideration that users will draw more than one polygon for sure to achieve like a city representation. So what we are really interested in is getting all the polygon tags from the given KML file. So let’s have a look how exactly the coordinates tags are buried in the XML structure when more than one polygon is being saved.

see pdf ver.

That kind of structure can be repeated of course (multiple folders), and is marked with closing tags. There can be different numbers of placemarks inside each folder as well. We are at the moment not considering the children other than coordinates tag. However we want to have ability to add code later for manipulating data on other tags in an easy way (placemark->name tag for instance which can serve us as a name for mesh3D object). I think that the best way to construct the behavior like digging the whole structure and taking just those tags that are interesting for us, would be using a recursive loop. We would call the method like proccesNode for children of each child encountered on the way, analyze it and if we find that it fits one of the tags showed on the outline above then call the proccesNode method for the children of that child (recursion) until we dig to the desired coordinates tag. In that approach we won’t omit any coordinates tag and in addition we can easily add code for finding another tag. Now if the tag is found we take the coordinates data which is represented as String and slice it using blank space as a token. After that we have an array of Strings where each of them is a triple consisting of “longitude, latitude, height”. So again we slice it, now using “,” token and we have a point data to make calculations on it. Here is the outline algorithm of proccesNode method that in full size can be found in Kml.as source file.

function processNode(children:XMLList) {

1. Loop for all children.
2. Get child tag name.
3. if tag name equals coordinates or other that has data – calculate the data;
4. if tag name is parent tag which can possess the tag with data - execute the recursion by fetching the children of that child to processNode method;

We can easily add further pieces of code by placing another “case” statement for specific tag. So now if we have data of any given point (longitude and latitude), how to convert it to a local coordinates? To points like (120,34,10) for instance. The longitude and latitude values in coordinates tag are expressed by degrees. So for instance here you have the two points which are creating edge of the building drawn onto Google Earth raster layer. Points are represented in (DD,MM) format degrees.

-122.1079075592149, 37.40374393714917, 28
-122.1084678195176, 37.40306635543301, 28

As you probably noticed the differences between those points are counted approximately in values like 0.0001. So for instance let’s consider one polygon case, flat in addition (only x,y). We would set the first point encountered as a world pivot and set it to 0,0,0 (storing however his longitude and latitude values as let’s say real pivot) then from each next point that we find we would subtract the real pivot longitude, latitude values which will give us the translation vector values for that point. If we repeat that process for all points we will end up with array of points with values like 0,002345. Then we can multiply it by a specified scale value and here it is. We got the points translated into more readable coordinate system. Ok but let’s verify the actual results by drawing the both figures onto map. Let’s place the figure that we achieve from square placed in Berlin to area near equator (subtract without multiplication). The results can be seen on the images at the bottom.

see pdf ver.
Fig.1 : Square polygon drawn in the city of Berlin.

see pdf ver.
Fig.2 : The same polygon moved to equator area (0,0 – longitude, latitude). Subtraction used.

Now we didn’t expect that to happen, did we? This is called the distortion problem of world projection and is strictly connected with creating maps in old Cartesian way. If we want to handle that problem we have to look for the same ways that 2D maps are created. The way presented above with distortions is also used in some cases in cartography because of the simplicity of calculus. In other hand distortions on maps are something that will always be there, we can only diminish its influence, we will never be able to fully avoid them. So have that in mind as well.
So how actually the maps are created? What at first glance looks as a simple question after a while can turn into a more specific question “how the hell that can be done?”. Maps in the past times were “simple” to draw because people assumed that the world is flat. And it would be so much easier for our project if the fact that the world is a spheroid was never discovered.
We are interested in moving the chosen part of spheroid world to plane Cartesian local map. What we need is a conversion which is called a map projection system. The traditional maps are much more compact, they are also better for city calculations, better and easier to view on paper or computer screen. All that led to development of many advanced ways of calculating the real world to Cartesian plane. There are numerous map projection systems, and their usage depends on what we want to achieve, what district we want to make map for, what distortions we are able to accept. Those are questions that we need to answer. The most popular types are cylindrical map projections, which is as you probably expect a projection of a sphere onto cylinder (like turning on the bulb inside the sphere which is inside cylinder). While this projection can be found in many maps available, it is strongly advised not to use it because of the large distortions, especially with high latitudes. The equator areas are the ones where the distortions are minimal while the north and south poles areas cover even up to nine times larger fields than in reality. There are several types of cylindrical projections. The most famous is called a Mercator projection. It was discovered in 1569 by Flemish cartographer Gerardus Mercator and became the standard map projection for nautical purposes, especially because of its ability to represent line with constant bearing (better known us rhumb lines) as straight line segments, which is commonly used to steer the ship in sea navigation (the full name of the first Mercator map was “New augmented description of Earth corrected for the use of navigation”, and was precisely for navy purposes). It means that if you draw a straight line on the map which is Mercator projection, that line would fit the loxodrome (rhumb line) in the real world, which can be easily set as a sailing direction using compass. In that projection the meridians and parallels are straight and perpendicular to each other, creating a grid which represents the world. Farer we go from the equator, the greater the distortions are. Normally above the 70 degree of latitude the distortions cause the data to be practically unusable. In addition we will never be able to view properly North and South Poles with that projection for instance – since the projection goes to infinity in that case. It was adopted fully in 18th century. Mercator however was not the only one that contributing into that type of map projection, behind the stage there were few other mathematicians that made it possible. Here you have the mathematic equations for the projection.
The Cartesian pair x and y is given by these equations. Where λ is a longitude of a given point, θ is latitude and λ_0 is the longitude of central point on the map.

see pdf ver.

Mercator projection assumes that the equator is tangent to the surrounding cylinder. This is an old fashion way to translate world into two dimensions. How about the projections that are used these days for creating maps? What is the modern approach on that issue?
As I said before there is a whole bunch of map projections that can be used, it mostly depends on the circumstances that we are in. However among them there is one considered to be a standard. If we have a projection now that can be considered as a standard, countries can easily merge areas in-between and standardize cooperation on international level (air traffic for instance). The projection that I’m talking here about, I’m sure you’ve heard it somewhere, is UTM which stands for Universal Transverse Mercator and as you probably figured it out it is an extended version of Mercator described previously. If you can imagine the simple Mercator, what would you change to make it more suitable for your specific purposes? For instance, if making map of the Leningrad area, the most suitable for you would be to move it exactly to equator area (minimal distortions). You can achieve that by moving the tangent circle to be not the equator but the meridian of your choice. That map projection onto cylinder with switchable tangent meridian is called Transverse Mercator. When using this kind of projection you will get a narrow area along the meridian of your choice with minimal distortions. That solution is much better in reality because although it diminishes the area that can be projected (North/South Poles are projected very well if using meridian, but some of the areas corresponding to normal poles position are not), it actually gives you choice which part of the world you can translate into Cartesian coordinates with minimal distortions (not only the equator areas). It’s really useful while projecting maps for countries like Chile. Distances like 5 degrees from meridian are giving 0.4% larger scale, for 10 degrees the value is 1.54%. This method based on Mercator of course, was first presented in 1772 by Johann Heinrich Lambert (with the spherical basis) and later by Carl Friedrich Gauss in 1822 using ellipsoid as a basis. Ok, now that you know what a Transverse Mercator is, let’s go further with it so that you see in outline how UTM (Universal Transverse Mercator) was founded. So hundreds of years passed again and the more sophisticated navigation systems for measuring distances needed to be invented, especially for military purposes. In 1947 United States Army develop UTM which is a type of grid based projection which means that it is a bunch of individual projections packed into one graphic representation. The UTM is separated into 60 individual parts (cylindrical projections) each encapsulating areas from latitude 84 degrees North to 80 degrees South and each of them 6 degrees wide (longitude). These zones are numbered from one to sixty. First is bounded by longitude 180-174 and centered on 177th West meridian. Zone numbers increase to east. As you probably expect each of these stripes is individual Transverse Mercator Projection, which used only in 6 degrees wide area gives us very little distortions and what is more they are diminished much more by taking the scale factor in the central meridian to 0.9996 so that the distortions are really minimal in the whole area. Notation of that system is based on the zone number and latitude letter. While the zone number is an easy guess, the latitude letter is a letter given from English alphabet. Each letter corresponds to area 8 degrees high starting from North Pole. Letters O, I are omitted because of the similarity to 0,1 values and the last X is extended by 4 degrees. The nice trick to remember is that N stands for first area of south hemisphere. A position referenced in the UTM system is as follows: UTM longitude zone, easting/northing coordinate pair. The easting is the distance from zone meridian while northing is distance from equator. To avoid dealing with negative numbers, easting for each zone is valued 500.000 meters on the centre, decrements to the west and increments to the east. The northing is valued 0 on the equator and increases to the north till 9,328,000 meters on the 84th parallel. As you go south form equator the northings decrease starting from 10,000,000. That way none of the points will have negative values and we have the way of translating the longitude and latitude to Cartesian map that we need. Let’s now have a look at the equations:

see pdf ver.

Where x, y is a pair of Cartesian coordinates after conversion, θ is latitude and λ is longitude. Now how to implement the UTM system to our solution? We would have to calculate it using the equations then use some parsing for getting the correct zones – but let me say something. If you look a bit deeper it’s too much, maybe not complicated but advanced and still possess some distortions if we consider distances like 2 feet long. So after all maybe using UTM would not be such a good solution for us, as it is mainly for representing large scale maps with minimal distortions. In our solution we want to get a representation of cities, university campuses, etc, in other words not the whole world or areas of country size. It would be good to stick with UTM standard, but as for now, with limitations that we are given with 3D in browser we should satisfy and focus ourselves with cities and therefore some other more specific projection type. However UTM can be implemented and used to represent world in 3D for purposes like route 3D map on airlines website. It would only consist of simple plane (UTM country or world map) and some boxes (airports) plus aircraft collada model for example, all visualized in a very fancy manner. So what I suggest is this time to use some projection that is based on a local area rather than on meridians, equators etc. I didn’t have to look far to find it, because such a projection is probably one of the oldest existing map projections and it’s reasonably simple as well. Let me introduce you to the gnomic projection.
Gnomon is an ancient Greek word meaning “indicator”. That name was given to the part of sun-dial that casts the shadow. Now try to correlate it with map projections, use your creativity and you get an idea what gnomonic projection is. Thales used his imagination and founded this oldest known map projection in 6th century BC. Ok, imagine the plane tangent to the sphere in only one point. The map is obtained by projecting the points laying on the sphere surface from the sphere centre onto the plane surface. As you can see on the picture below the projection can be used only for one hemisphere at once (if not - antipodal points would lay one on another). The tangent point can be set wherever we want it to be, which is exactly what we were looking for. Imagine now for instance that we are going to set it as a first point ever found in KML file. That way, distortions would be almost none in our local area (city size map). The specific thing about gnomonic projection is that it always will show great circles as straight lines, and because of that ability it is commonly used in fields like seismology or military (seismic waves and radio signals tend to travel along great circles). The projected map has huge distortions if you would look at its full hemisphere view. It is exactly like looking through spherical lens. However if you want it to project a map for country size region (not Russia or US of course) you can go for it. Just place the tangent point in the center and you will have a pretty realistic projection. And as you remember, we are mainly interested in city size maps, so in other words we will have huge space reserves for our local city and really minimal distortions in addition. It would be perfect for us with its simplicity as well. Here is some math for gnomonic projection:

see pdf ver.

Where x, y corresponds to Cartesian coordinates after conversion; θ, λ is latitude and longitude of given point; θ_0, λ_0 are latitude and longitude of central point; c is an angular distance between actually measured point and the central point of projection, its value is given by equation:

see pdf ver.

There are again variety of modifications with that plane projection (plane intersecting the sphere, gnomon point in infinity), but we really don’t need to make things more complex, that one is more than enough for our calculations and if you check the shapes that you get from that projection you won’t see a difference.

by Marcin Czech

3D world in browser... just like that

You can get the pdf version with images here

The world is xmlizing... I say. Every data type on the web got to be in XML. That is good, that means open data, human readable data, more accessible for society in all fields, wherever XML is used. XML is ubiquitous these days.
3D in internet has a long and interesting story, it has started with VRML technology. Plenty of companies were making their own plug-ins, selling, showing their enormous functions, but there was no standard. It was hard to think of it, while the OpenGL support was barely standing and HTML was exploding on the net. People started talking how buggy and not efficient that kind of solution is. So VRML stayed in a shadow. That was years ago, some people had this dream about 3D worlds in a browser, true 3D API with decent data for it. Years passed and a successor of VRML came into stage, X3D.
X3D is a ratified standard from Web3D Consortium, it grew up to become next child to fight its way with browsers. X3D is XML based, it includes old parts of VRML such as H-Animation, GeoVRML or Nurbs. It replaces VRML while providing compatibility which VRML existing content (VRML content can be read by X3D reading applications). It was developed so that it is extensible and shrinkable as well. It consists of profiles, which include components. Components are collections of specific features. For instance we have Geo component. The reason of such a construction here is that some companies wouldn’t like to support all of the features available with X3D, so they shrink X3D to their specific X3D data. They can also create new profiles and components. The solution is universal as you can see. There is another very popular XML data for 3D representation – the Collada file (DAE extension). They are very similar as it comes for construction. Both the Web3D and Khronos Group (actual owner of Collada - originally was made by Sony) are collaborating so that they can specify fields where each of them will find its piece of land, they also want to make some of their parts the same (animation etc.) so that the open source society will have more profits. So if both are XML can we...? yes, we can make translations between them. There are XSLT transformations available, free of charge of course. However, in big outline... Collada is considered as a interchange format for standalone DCC (Digital Content Creation) applications, while X3D is focused on web issues. If you want to have a broader view on X3D/Collada there’s a fresh whitepaper from Tony Parisi [1] on this subject. So we have X3D, why I find it so important for GIS Web 3D. Primarily, because it is a standard, a good stable standard, with really some time spent on developing its flexibility. Secondly it has a working group X3D Earth working group which vision is to create X3D representation of the world, I know that’s a big challenge, but they have some serious reinforcements as well (NASA). Anyway, there are also some other non-standard technologies that have something to say if it comes to GIS data. There is very nice cityGML which has some cities already implemented in it (www.cityGML.org), but it’s not yet a standard. At the moment it’s on its way of achieving that with Open Geospatial Consortium. However for web purposes X3D should take the lead. Heh, again cityGML is XML so yes, again XSLT to X3D is possible. More on that topic is covered in Kiwon Lee document[2] about literally speaking cityGML to X3D transformations and mobile GIS 3D. So we are here at the point where we have data type X3D which is supporting our GIS and what is more is web focused, but what about the viewer?
The Web3D Consortium provides us with some free X3D viewers. But all of them are required as new plug-ins for our browsers in case we want to view something, and that’s a bit of a problem. Because a good stable player is also very important if it comes to Internet society, in some way standardized player. I know that if someone really would like to use 3D in web he would download the player and play it. But as far as I know reality, people are not keen on installing new plug-ins, most of them don’t know how to do it (despite it is automated these days). That’s life. My point here is that the 3D that we have to offer should be playable just like that, when opening the web page. Like google maps, that’s why they are so popular. There is NASA WorldWind and Google Earth as well (the standalones), but the usability is what counts nowadays and what makes people speak about it. The practical usage of solution.
There is one plug-in however that is available among society, yes, exactly... Flash Player. Everyone has Flash Player. To be more concrete I will recall the chart from www.adobe.com (Fig.1)

Fig. 1 : The Adobe Flash Player statistics show that Flash content reaches more than 98% of users.

Yes I know that can be a bit exaggerated (those are Adobe statistics), but It’s hard to admit that the Flash Player is not ubiquitous.
So Flash, Flash, wasn’t that just for 2D vivid graphics? Yes it was, it is, and it’s evolving. But in the mean time we want to get started here with new Adobe Flex 2.0 technology which also uses Flash Player as a run-time environment. I gave you before an example what Flex ArcWeb Explorer is, and how ESRI was fascinated about it. Imagine now connecting 3D options to it. Well I believe it’s fully applicable. As I said before, we want to create very portable and practical solution. The point I’m making here is that in my opinion the X3D, Flex + Papervision3D bundle gives as a gate to develop really nice looking environments in a really fast way. There are many gaps still to be filled with some coding, but the outline is there, steady and ready. Ok so are we ready to show some graphics? what else do we need? ... Rationality! and again the practical attitude. I’m going to keep repeating that till the end of my days. The public destination of that solution and the availably for everyone is a really important issue. People are creating standards these days, not companies. So which part of our gate needs to be replaced?... what about X3D, do we have some data implemented in it? is it really in practical, wide usage? No it isn’t. My sentiment about X3D is similar to this expressed by French president Charles De Gaulle about Brazil: It has a great future … and always will. We need something practical, what is already in wide use, and its growing in the hand of the users, and moreover we need it now. X3D is supported by NASA and it maybe going to be a standard but nowadays we need to pick up something reasonably, that will strongly support us with existing data. The best way to see what I mean is to compare NASA World Wind and Google Earth. Google Earth is starting to be created by users for users, and that is what I call a standard. So what I advise to myself, is to use the kind of data that is using Google Earth to represent environment. So here we are now with KML (it seems that we are going through all the alphabet +ML extension). You see, the easiness with I am switching the data types is also because of the fact that all of them are XML based and its possible to make translations between them, we are not risking much. So again,my target is the type of that data that will be most suitable for wide audience providing ease of use and data creation perspectives. So what about this KML you ask?

KML stands for KeyHole Markup Language. The word Keyhole is an earlier name for the software that became Google Earth. The software was produced in turn by Keyhole, Inc, which was acquired by Google in 2004. The term "Keyhole" actually honors the KH reconnaissance satellites, the original eye-in-the-sky military reconnaissance system now some 30 years old. At the moment it is a standard of representing data for Google Earth apps. It is constructed with really simple structure. Let’s say we want to mark a point on Google maps. The KML file would be as follows :

example in pdf version;

That gives us points, nothing special. But the KML can support us with polygons descriptions :

example in pdf version;

Fig. 2 : Different types of polygons in KML, opened and placed on a specific location in Google Earth.

What is more, we can use Google Earth to create that kind of polygons using real world raster map as a drawing layer. So that way we can acquire polygon boundaries created on real world blue prints with real world coordinates. That is kind of fun. I wouldn’t lie if I say that starting from now, with no experience in Google Earth, I can create in few hours an outline of a small city and export it to KML files, or create KMZ archive (collection of KML files). Just like that, that is what I call simplicity. Ok let’s go further. Starting from KML version 2.1 Google made a big step towards 3D worlds, we have a support for intermediate 3D modeling file format, guess… yes, our gaming friend Collada (thought about X3D, huh?).

So… plenty of new possibilities now open. Game creators can move their actual work to Google Earth engine. Anyone can model buildings in his favorite application save it to Collada file and place it in the Earth on a specific coordinates. I don’t have to tell what kind of options it gives. Can you imagine games in real 3D environment or millions of people creating 3D models of their homes? Well, it’s going to happen faster than we think, I think. In the mean time… where were we with our lounge of chosen technologies?

Fig. 3 : The KML file with a Collada .dae model attached to it, opened in Google Earth.

Our gate for creating 3D worlds, based on true Geographical data, open for everyone in a common browser is : Flex with PaperVision3d + KML file format which includes Collada files. In my opinion that could be a really interesting solution solver for Web based GIS 3D. It is really easy to develop, and if you take a deeper insight on options which each of these technologies give, you will see that you can create some really fresh outlook of content in a web browser… just like that.

By Marcin Czech


References :
[1] ”Developing Web Applications with COLLADA and X3D” by Dr. Rémi Arnaud and Tony Parsi
[2] “Prototype Implementations for Multi-typed 3D Urban Features
Visualization on Mobile 3D and Web 3D Environments “ by Lee Kiwon

GIS 3D, data support

GIS systems are based on the vast amount of data. And we are talking here about maintaining enormous databases which eventually have to be updated as well. However, still there is a lot of static-data, based on offline sources - CD’s for instance. We have to bear in mind that when it comes to decisions or visualizations made in GIS, we got to keep that data as fresh as possible in order to make GIS and our work valuable. And I’m not talking here about putting it into fridge, but about feeding it with newly comers, as soon as they pop up. The very nice option appeared some years ago, Web Services, which seems to fix the problem. All we need is internet connection and bought/free access to such resources. After that we will be getting most updated data that is available and be always up-to –date. In these days reality likes to change on daily rate, heh even hours or minutes matter. Short cut, as for today, future data support for apps lays exactly in there. That kind of solution would be more than fine for us, as we want our project to posses distributed system as well (that would provide more solutions for future and after all it is server based system). However I think we would like to update it with some more detailed local data as well, monuments made in 3D Studio Max for example, so no worries... I’ll try to cover that as well. What about availability of such a WS you ask? Well yeah, there is not much, but enough to start I would say. Web Services are still in early phases when it comes to GIS. They can provide answers for simple queries like latitude and longitude for given address, but when it comes to more sophisticated data - problems appear. ESRI has Web Services on public/student license available for one year period, with limitations of course. All you need to do is, go to company web page and register then subscribe for Web Services license. I’m not sure exactly what sort of data these services provide at the moment but I’m sure we can make something out of it to show that it works. Ok I’m talking here about data and stuff but did I mention that it is 2D raster, vector or text based data? Nop?
Data - a very important and vital component for our project. It’s nature has to be a bit different than the nature of existing data sources. As we remember we wanted it to describe 3D objects. Hmm.. so not having found existing, satisfying internet solutions I gathered some pointers which I think we should consider. Primarily the basic – the data has to have ability for describing 3D objects as well as 2D. Secondly it has to be simple, so that we could for example parse it by ourselves to write/read some of its properties (even at runtime). It has to be lightweight as it will be struggling through internet from server-side or Web Services if we would use them. There are actually very simple solutions that we could use – first that immediately popped up out of my mind is XML of course. Then there is Collada 3D file based again on XML language – lightweight and supported by almost all of 3D modelling apps. So I think, with storing the data we would have no problem, at least in that early phase.
So the real question here is where we are going to get data from? The most preferable would be using Web Services – but I haven’t found ones that would give us answers, for example like - building boundaries – that we could use to build a polygon. ESRI WS provides you with types of data like text based or Map Image raster generated on server, which is not suitable for us (but we could use it for more fancy things -> making a true texture for sky polygon = true weather). So next step I think, the best one is to look for existing data sources – no matter if it is online or offline resource (as long as we make our solution universal, and ready when that kind of data will be available through the net). Find the ones that are based on XML files (or are easy to convert) and would provide us with true, geographic polygon like data. Here is an example to show you what I mean. Bear in mind that this kind of data simplicity is desired, especially in these days (internet connection speed, 3D browser engine limitations). For instance:
{area id=”1234”}
{building id=”museum” video=”http://museum.com//Welcome.avi” }
{FirstCorner} x=120,y=123,z=0{/FirstCorner}
...
{/building}
...
{/area}

If we could find that kind of data, we are ready to go, to create some visual basics. Yeah, and what if that kind of data doesn’t exist? I’m going to answer that in a non scientific way - I’m always optimistic and my intuition again tells me that there is something that we can make use of, it just seems so logical that it exists.

By Marcin Czech

FLEX and 3D is it possible?

While I was digging the web trying to answer that question I must say I already had an assumption about it. Well these suspicions were mainly because Adobe Flex is based on Action Script 3.0 and Adobe Flash which is... let’s say the technology which had a big influence on the new child of Adobe, is mostly AS ver. 2.0. And as I have already seen some 3D solutions in Flash AS2, so it was very possible that it is the same with Flex, however it had to be checked.
So by simply typing “Flex 3D” in google I started looking for existing solutions. Well it turned out that there are not many, to be honest just a few. One of the best and very interesting Flex Apps is located here :
http://flexarena.blogspot.com/2006/10/3d-wireframe-renderer-for-flex.html
by Anjali Bhardwaj.
It consists of a wireframe renderer which loads 3Dmax ASE format and XML mesh models from the server side, however it is very primitive and simple, without textures and so on.. but that’s not the point here. By simply watching this example we are in some sort of way assured that it is possible to render and load objects which is really important from our point of view... in which, in the future we would like to use that kind of solution as a basis for our GIS 3D object oriented system. After digging some more, I have to say that it is really little done in 3D and Flex at the moment, and there are several reasons why.
First of all – why do something that is already done. Well as I said before Flash and Flex have more similarities than differences. Main difference is that the source file for Flash is a binary FLA which is compiled among with AS classes in Flash IDE to swf file which is later hosted on a server. Flex can deploy MXML(XML based) files and AS classes on the server which is generating swf files at runtime, that’s cool. Not having source in binary format is also important because it gives Flex ability to do for example ver. control on files. Well there are much more differences in server-client communication structure but my point here is that we should look for some really good 3D solutions for Flash and find out if they are able to take a leap to Flex environment.
Ok. Finding 3D solutions was quite easy. There are already some commercial products and also some open source approaches. Well 3D in Flash requires a bit more explanation because Adobe doesn’t support native 3D – no OpenGL or DirectX. There are some gossips saying that they are working really hard on it. Well these gossips could not be certified until I could get in touch with Adobe team, heh and I don’t think they would share their plans with me. So let’s pause on this thread for a second.
In the meantime let’s look at some non-native 3D solutiuons - software only. First is so called pre-rendered sprite approach. You create object with software such as Maya, Blender, Max or other.. then you render it from several angles and place it in Flash. It’s completely fake 3D. You can create really marvellous and vivid sites with that, because the only limit you get is the one with your software. However interaction is really limited so this is no good for our GIS purposes. Another approach is a real 3D engine, there are several at the moment and they differ on the ways of rendering. After taking a closer look at these beauties – documentation, license, source, examples, features and so on. I specified two possible candidates with are fully open source so that we can mess with the code. The names are Papervision3D (http://www.papervision3d.org) and Sandy3D (http://www.flashsandy.org). PV3D has a great advantage of being already implemented in AS3 what makes him much faster than Sandy. Ok now let’s invoke the thread that we paused before.
In this point a question arises... If the gossips about Adobe and its native 3D are true, is that a proper way that we’re going to follow with open source engines? Huh, well that’s a really good question because in that case most of the existing 3D engines will have to revise again their main goals, because if Adobe would release 3D engine it would probably wipe out all the existing ones. But, we are not sure at the moment what adobe plans right now... and in the other hand I truly doubt that hardware supporting engine for Flash would be such a good move for Adobe, in some way they would lost their platform independence. So, fake 3D engines can live. Especially bearing in mind that their performance is based on CPU speed, which is increasing these days month by month. At the moment PV3D engine based on AS3 is able to view 20.000 polygons per second which gives us 1000 in 20FPS. That is a really nice result and I think it should be enough for our GIS 3D project.
Ok, so now the answer... so Yes it is possible to render 3D environment in Flex. However there are some limitations which we should always keep in mind. Our goal here is to create simplicity, just like google maps or ArcWeb Explorer are using vector representation our priority is also to keep it as simple as possible while supporting many ways of evolution for future purposes.

Project GIS and FLEX 3D started

Aloha!
I started working on my research about GIS (geographical information systems) few weeks ago. As I explored the subject deeper, I found that its evolving really fast and the possibilities that it gives... well they can have tremendous influence on our society in next years, to be honest I truly believe that the future lays there.. hehe I can imagine governors playing SimCity like game on GIS software, they virtually place a home -> application sends job specification to construction group and they start their work... ok futurismooo but possible.... so after reading some articles especially about ESRI using they latest tool ArcWeb Explorer :
http://mxdj.sys-con.com/read/295386.htm
http://www.spatiallyadjusted.com/2006/06/29/esri-is-a-adobe-flex-2-success-story/
and because I'm quite familiar with the Adobe Flex 2 technology abilities.. I thought, why not to go further and develop three dimensions interface in Flex 2.. Imagine going through the cities and looking from first person perspective view. That would be cool. Well to be honest if we could develop 3D abilities in Flex, that kind of solution would affect not only GIS but also navigation on Web applications and online gaming as well. Its worth seeing what can be done in that direction.. So lets start.. this week I'm gonna dig the web in search of existing solutions for 3D in Flex.

Any comments, pointers and suggestions would be most appreciated.
Saludos!

Marcin
http://sauax.boo.pl