Ok, so I have an upcoming project in mind. Burning Man. I find the most compelling images in Google Street View are the ones that show people in their element. It's like a snapshot of an entire city. I'd like to recreate the same thing at Black Rock City this year. The streets are already laid out, and it's possibly one of the most interesting geospatial web projects because the community actively writes about themselves using the PlayaInfo platform. It's not built on traditional geographic systems, but it's still very cool, and it would be amazing if we could make the whole project more rich by incorporating panoramic data of the streets, every 100 feet.
I'm not completely sure how to accomplish this because I don't have a huge budget, but I really want to make it happen because I think it's good to have a goal, and it's an opportunity to capture people at their most creative, in a very temporary setting. If you went to the site where Burning Man is held right now, you wouldn't see much other than a flat, dusty, lake bed. Here are some links you might find interesting: - Burning Man Panoramas: http://pic.templetons.com/brad/pano/bman06.html - PlayaInfo: http://playainfo.org/ - Burning Man: Google Earth: http://bmearth.burningman.com/ - Internet at Burning Man (site last updated in 2004, but still very active): http://www.eugeneweb.com/~bm/ibm.html - High Resoultion Aerial Photo of Burning Man 2006 (3900x4000 px) : http://www.flickr.com/photo_zoom.gne?id=237120629&size=l - My Burning Man Maps (collected from various sources): http://igargoyle.com/archives/2005/08/mapping_burning.html Tom Longson (nym) On 6/12/07, Mike Liebhold <[EMAIL PROTECTED]> wrote:
Rich Gibson wrote: I'm going out on a limb here to say that I think doing open street views is (primarily) a project in hacking community rather than code. Actually there -is- an important question of code. Does creating an "open" streetview imply creating new notation or markup? Or simply applying the new features in KML2.2? see: http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#photooverlay ... <!-- specific to PhotoOverlay --> <shape>cylinder</shape> <!-- kml:shape --> <ViewVolume> <distance>0</distance> <!-- double --> <leftFov>0</leftFov> <!-- kml:angle180 --> <rightFov>0</rightFov> <!-- kml:angle180 --> <bottomFov>0</bottomFov> <!-- kml:angle90 --> <topFov>0</topFov> <!-- kml:angle90 --> </ViewVolume> <roll>0</roll> <!-- kml:angle180 --> <Point> <coordinates>...</coordinates> <!-- lon,lat[,alt] --> </Point> <ImagePyramid> <tileSize>256</tileSize> <!-- int --> <width>...</width> <!-- int --> <height>...</height> <!-- int --> </ImagePyramid> </PhotoOverlay> *Description * The <PhotoOverlay> element allows you to geographically locate a photograph on the Earth and to specify the placement and orientation of the Camera that views this PhotoOverlay. The PhotoOverlay can be a simple 2D rectangle, a partial or full cylinder, or a sphere (for spherical panoramas). The overlay is placed at the specified location and oriented toward the Camera. Because <PhotoOverlay> is derived from <Feature>, it can contain one of the two elements derived from <AbstractView>—either <Camera> or <LookAt>. The Camera (or LookAt) specifies a *viewpoint* and a *viewing direction*(also referred to as a *view vector*). The PhotoOverlay is positioned in relation to the viewpoint. Specifically, the plane of a 2D rectangular image is orthogonal ("at right angles to") the view vector. The normal of this plane—that is, its front, which is the part with the photo—is oriented toward the viewpoint. The URL for the PhotoOverlay image is specified in the <Icon> tag, which is inherited from <Overlay>. The <Icon> tag must contain an <href> element that specifies the image file to use for the PhotoOverlay. In the case of a very large image, the <href> is a special URL that indexes into a pyramid of images of varying resolutions (see ImagePyramid<http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#imagepyramid> ). *Elements Specific to PhotoOverlay * *<shape> * The PhotoOverlay is projected onto the <shape>. The <shape> can be one of the following: *rectangle* - for an ordinary photo *cylinder* - for panoramas, which can be either partial or full cylinders *sphere* - for spherical panoramas *<ViewVolume>* Once you have positioned the camera in space and oriented it, you need to define how much of the current scene is visible. Specifying the field of view is analogous to specifying the lens opening in a physical camera. A small field of view, like a telephoto lens, focuses on a small part of the scene. A large field of view, like a wide-angle lens, focuses on a large part of the scene. The field of view for a PhotoOverlay is defined by four planes, each of which is specified by an angle relative to the *view vector*. These four planes define the top, bottom, left, and right sides of the field of view, which has the shape of a truncated pyramid, as shown here: *<distance> * Measurement in meters along the viewing direction from the camera viewpoint to the PhotoOverlay shape. *<leftFov> * Angle, in degrees, between the camera's viewing direction and the left side of the view volume. *<rightFov*> Angle, in degrees, between the camera's viewing direction and the right side of the view volume. *<bottomFov> * Angle, in degrees, between the camera's viewing direction and the bottom side of the view volume. *<topFov> * Angle, in degrees, between the camera's viewing direction and the top side of the view volume. *<roll>* Adjusts how the photo is placed inside the field of view. This element is useful if your photo has been rotated and deviates slightly from a desired horizontal view. *<Point><http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#point> * The <Point> element acts as a <Point> inside a <Placemark> element. It draws an icon to mark the position of the PhotoOverlay. The icon drawn is specified by the <styleUrl> and <StyleSelector> fields, just as it is for <Placemark>. *<ImagePyramid>* For very large images, you'll need to construct an image pyramid, which is a hierarchical set of images, each of which is an increasingly lower resolution version of the original image. Each image in the pyramid is subdivided into tiles, so that only the portions in view need to be loaded. Google Earth calculates the current viewpoint and loads the tiles that are appropriate to the user's distance from the image. As the viewpoint moves closer to the PhotoOverlay, Google Earth loads higher resolution tiles. Since all the pixels in the original image can't be viewed on the screen at once, this preprocessing allows Google Earth to achieve maximum performance because it loads only the portions of the image that are in view, and only the pixel details that can be discerned by the user at the current viewpoint. When you specify an image pyramid, you also modify the <href> in the <Icon> element to include specifications for which tiles to load. *(Documentation with specific examples to be provided.)* *<tileSize>* default = 256 Size of the tiles, in pixels. Tiles are square. A tile size of 256 (the default) or 512 is recommended. The original image is divided into tiles of this size, at varying resolutions. *<width> * Width in pixels of the original image. *<height>* Height in pixels of the original image. *Example* *<PhotoOverlay>* <!-- Feature elements --> <name>A simple non-pyramidal photo</name> <description>High above the ocean</description> <!-- Overlay elements --> <Icon> <!-- A simple normal jpeg image --> <href>small-photo.jpg</href> </Icon> <!-- PhotoOverlay elements --> <!-- default: <shape> --> <ViewVolume> <distance>1000</distance> <rightFov>60</rightFov> <bottomFov>-45</bottomFov> <topFov>45</topFov> </ViewVolume> <!-- default: <roll> default is 0 --> <Point> <coordinates>1,1</coordinates> </Point> <!-- if no ImagePyramid only level 0 is shown, fine for a non-pyramidal image -->*</PhotoOverlay>* *Extends* - <Overlay><http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#overlay> *Contained By * - <Folder><http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#style>, <Document><http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#document>, or <kml><http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#kml> Panorama tools for stichting/manipulating images seem to be a solved problem (where 'solved' means it is either solved, or there is a large community actively working to solve the open issues)... For example, Panotools has five Google Summer of Code students working on things... http://panotools.sourceforge.net/ We'll need to create some glue to automate things, but the heavy lifting code exists... so what are the open questions? -setting up multliple cameras -exposure control for the different cameras -capturing location - 'obviously' GPS, but I suspect we'd like AGPS resolution, and probably a compass independent of the GPS track (ie. built in compass seems okay, but counting on the track log requires you to be moving , and isn't all that accurate. :-/ -Processing images-panotools seems to have what we need. -storage-initially a random server will work. -API to access imagery -> seems like 'a few scripts' -viewer - panorama viewers exist already, but we would like some cool map based interface next to the panoramas. These don't seem like hard questions, but I don't have off the cuff answers for all of them. Any questions I'm missing? Any answers? Cheers, Rich ------ A couple other cool links: http://www.bruno.postle.net/neatstuff/ip-slicer/ 3d physical printing http://www.philohome.com/rhombicuboctahedron/rhombicuboctahedron.htm On 6/12/07, Tom Longson (nym) <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>wrote: Having run http://igargoyle.com/ since 2002, I don't see that happening anytime soon. Anyways, this is digressing a lot, anyone have experience setting up multiple cameras to capture panoramas? Anyone have experience stitching these images? Thanks, Tom Longson (nym) http://igargoyle.com/streetview/ On 6/12/07, Andrew Larcombe < [EMAIL PROTECTED]> wrote: > > On 12 Jun 2007, at 21:54, SteveC wrote: > > > > > On 12 Jun 2007, at 19:59, Artem Pavlenko wrote: > > > >> This is how you might want to mount your cameras: > >> > >> http://www.yotta.tv/ > >> > >> Anyway, building panoramas is not really interesting. Think bigger > >> and start building 3D. > > > > As a more general thing... I don't understand 3D as a UI. > > > > I spent a ton of time in 3D when the new hotness was VRML. I wrote > > things to take a set of photos and magically turn them in to models > > and so on. At its base it seemed like you spent 1000% more > > development effort to make a 3d model of your building/city for a > > 1% improvement in usability. You got some factor of whizzyness, > > it's a great educational tool, but no real ROI in its own space. > > > I think the problem is we're still using mostly 2d technology to > interact with these computer things which makes a 2d gui more > natural. 3d will be great when we've all ditched our trackpads and in > favour of immersive hardware - 3d headcams & gloves. Or a holodeck - > whichever comes sooner. > > Cheers, > > A > --- > Andrew Larcombe > Freelance Geospatial, Database & Web Programming > > email: [EMAIL PROTECTED] > icq: 306690163 > > > > > _______________________________________________ > Geowanking mailing list > [email protected] > http://lists.burri.to/mailman/listinfo/geowanking > _______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking _______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
_______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
