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
<file:///C:/Documents%20and%20Settings/josiew/Desktop/KML22/WhatsNewInKML22/photos.html#viewVector>/.
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]> 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
