Street View Tour
111 views
Skip to first unread message
tcorbet
Jul 23, 2008, 11:47:51 AM7/23/08
to KML Developer Support - Google Earth Browser Plugin
If this question/request is not appropriate in this Group, please let
me know which Group to try next. I have tried Google Earth with no
luck except the suggestion to try here.
01. The GE Users' Guide tells me how to save a Street View to My
Places.
02. The GE Users' Guide tells me how to snapshot my particular Point
of View for that marker.
03. The GE Users' Guide tells me how to Tour Places.
The problem is that the Point of View for a set of Street View places
does not seem to be persisted properly in the KML. When the marker
sites are rendered, we are back to the 'default yaw' from the original
photograph.
I have explored the Map API and determined how to:
A. Locate the nearest Street View, and
B Calculate the yaw that will re-orient the Street View to the
direction in which the viewer needs to be looking for the Tour to make
sense, but
C. I have no idea how to construct a Tour via the Map API.
I am confident that all the fine features of a GE Tour would be
retained, and I would not have to write Javascript if the tags and
attributes of the KML could be cooerced into preserving that
information. In the absence of a KML representation of the Street
View including the camera Look At, the touring facilities of GE with
regards to Street View are almost unusable. To go back to the real
world from the virtual, it is as if you took a bus tour through New
York City and the driver had to say, "Everyone come look at what I
see out the front window of the bus!." except what I think is really
happening is that we are forced to look out the front window of the
little Volkswagon busily photographing the world. The default
orientation preserved in the panoId is NOT the orientation that almost
any conceivable Tour will want to present.
So, I am pretty certain that Street View challenges belong to the Map
folks, and that Touring challenges belong to the Earth folks, but the
common denominator that lets us put them together is a challenge for
the KML folks. So, I hope someone here can tell me how to meet the
challenge. The semantics and syntax of the KML 2.2 specification seem
to be more than sufficient to preserve the 3D camera angle attributes.
Thank you.
me know which Group to try next. I have tried Google Earth with no
luck except the suggestion to try here.
01. The GE Users' Guide tells me how to save a Street View to My
Places.
02. The GE Users' Guide tells me how to snapshot my particular Point
of View for that marker.
03. The GE Users' Guide tells me how to Tour Places.
The problem is that the Point of View for a set of Street View places
does not seem to be persisted properly in the KML. When the marker
sites are rendered, we are back to the 'default yaw' from the original
photograph.
I have explored the Map API and determined how to:
A. Locate the nearest Street View, and
B Calculate the yaw that will re-orient the Street View to the
direction in which the viewer needs to be looking for the Tour to make
sense, but
C. I have no idea how to construct a Tour via the Map API.
I am confident that all the fine features of a GE Tour would be
retained, and I would not have to write Javascript if the tags and
attributes of the KML could be cooerced into preserving that
information. In the absence of a KML representation of the Street
View including the camera Look At, the touring facilities of GE with
regards to Street View are almost unusable. To go back to the real
world from the virtual, it is as if you took a bus tour through New
York City and the driver had to say, "Everyone come look at what I
see out the front window of the bus!." except what I think is really
happening is that we are forced to look out the front window of the
little Volkswagon busily photographing the world. The default
orientation preserved in the panoId is NOT the orientation that almost
any conceivable Tour will want to present.
So, I am pretty certain that Street View challenges belong to the Map
folks, and that Touring challenges belong to the Earth folks, but the
common denominator that lets us put them together is a challenge for
the KML folks. So, I hope someone here can tell me how to meet the
challenge. The semantics and syntax of the KML 2.2 specification seem
to be more than sufficient to preserve the 3D camera angle attributes.
Thank you.
Roman N
Jul 24, 2008, 3:56:29 PM7/24/08
to KML Developer Support - Google Earth Browser Plugin
tcorbet,
The inability to store the default view location within PhotoOverlays,
which are used to store Street View panoramas, is a limitation in the
KML specification. Also, the Earth API does not fully support
PhotoOverlays yet.
You could store a placemark (marker) for each Street View panorama
that would serve as a 'look at' location. The Maps API Demo Gallery
has a great example on how to make a Street View window look at a
given point: http://gmaps-samples.googlecode.com/svn/trunk/streetview/angletowardsbuilding.html.
I would also recommend checking out the other Street View related
examples at http://code.google.com/apis/maps/documentation/demogallery.html?searchquery=&classname=GStreetviewPanorama.
To simulate a tour of multiple locations, you could pull the list of
tour stops from your KML file by using GXml from the Maps API (http://
code.google.com/apis/maps/documentation/reference.html#GXml) and use
some basic JavaScript to pan to the different locations.
This is a fairly complex solution, requiring a fair amount of
JavaScript knowledge. If you'd like to go this route, definitely start
with some of the samples available at the Maps API Demo Gallery I
mentioned before. And for more help, check out the Maps API group at
http://groups.google.com/group/Google-Maps-API. If you plan on using
the Earth API as well, then please post your questions here too!
- Roman
The inability to store the default view location within PhotoOverlays,
which are used to store Street View panoramas, is a limitation in the
KML specification. Also, the Earth API does not fully support
PhotoOverlays yet.
You could store a placemark (marker) for each Street View panorama
that would serve as a 'look at' location. The Maps API Demo Gallery
has a great example on how to make a Street View window look at a
given point: http://gmaps-samples.googlecode.com/svn/trunk/streetview/angletowardsbuilding.html.
I would also recommend checking out the other Street View related
examples at http://code.google.com/apis/maps/documentation/demogallery.html?searchquery=&classname=GStreetviewPanorama.
To simulate a tour of multiple locations, you could pull the list of
tour stops from your KML file by using GXml from the Maps API (http://
code.google.com/apis/maps/documentation/reference.html#GXml) and use
some basic JavaScript to pan to the different locations.
This is a fairly complex solution, requiring a fair amount of
JavaScript knowledge. If you'd like to go this route, definitely start
with some of the samples available at the Maps API Demo Gallery I
mentioned before. And for more help, check out the Maps API group at
http://groups.google.com/group/Google-Maps-API. If you plan on using
the Earth API as well, then please post your questions here too!
- Roman
tcorbet
Jul 25, 2008, 1:37:30 AM7/25/08
to KML Developer Support - Google Earth Browser Plugin
Thanks for getting back to me, Roman.
In the interval since making my posting, I have not only continued to
research the topic, but to write/test as much code as I can. [In an
answer to your related questions: Yes, I think the application, when
properly implemented, will require both the Map and the Earth apis.
Moreover, since I think the application probably needs some of the
animation and additional 3D capabilities most readily obtained from
the Flash environment, I expect to need that integration. For those
reasons, and since the Earth api, as far as I can find, is scarcely
documented outside of Google's labs, and since the Map api, at this
time, does not include Street View, the code I am writing tests both
Javascript and Actionscript via your Flash api where it exists, or via
ExternalInterface, where it does not.]
Since there is more information that I can uncover in the Map groups,
I have worked more on that aspect for the last 24 hours. I am at the
point where I think I can say that there appears to be no generally
valid way to take the results from a geocode query based on a street
address, and computationally determine the correct yaw for a LookAt
that address from the 'nearest' Street View.
I seem to find that anyone who has posted a 'solution' for any
application making a similar request has had to resort to somehow
obtaining independent LatLon references points for the desired LookAt
targets. Some report using other geocode sources than you provide,
others report just performing some manual entry into some database
after manual investigation and refinement of the data from your
geocode sources. The nice demos to which you refer, in fact, all have
that dependency. If it is ok to ask the user to move a pointing
device -- a couple of feet up, a couple of feet down, a couple of feet
left, a couple of feet right -- the results of an atan2 function call
can yield the right answer. The question is how to get the right
answer when there is no operator intervention -- when it really is a
software-guided tour, and when most of what is generally known is the
ordinary address of some residence or business establishment and there
is no user hinting at the correct azimuth angle.
So, coupling that with what you have suggested, it seems that any
solution, given the presently available data, requires a database that
can yield the correct LookAt between two know points. Let's assume
that we make that investment in data collection. That, then, focuses
the effort on the animated visual effects of moving from one 'scene'
to another 'scene'. What is your recommendation in terms of the
direction of the Map and Earth aps? I think many folks could benefit
from a small planning matrix.
Take two 'size points': Applications very needful of a small resource
footprint, and applications for which resources -- be they network or
workstation are not a problem.
Take two 'apis': Map and Earth.
In the four cells, what's the recommended development direction for
RIAs that have the common characteristic of a user experience that can
be called a 'tour', by which I think I just mean, that [as contrasted
with a transaction], the user is primarily just sitting back and
watching and listening as the tour plays its natural course from start
to finish.
The nice thing about the current Earth integration of a Street View is
that the person creating the guided tour actually solves the problem
-- very precisely. If that snapshot set of attributes were correctly
captured, we would have what we need at playback time. It is actually
far superior to use the Earth UI to capture the complete orientation
-- including, where helpful, both zoom and tilt. The demos from the
Map api -- coming from a 2D world -- don't even address those two
additional attributes.
Sitting way outside your labs [though I can ride my bike down the
Guadalupe bike trail to get to your towers from Campbell], it sure
seems like the easiest, quickest, best fix would be to use the Earth
part of your toolkit to fix the missing KML data model.
In the interval since making my posting, I have not only continued to
research the topic, but to write/test as much code as I can. [In an
answer to your related questions: Yes, I think the application, when
properly implemented, will require both the Map and the Earth apis.
Moreover, since I think the application probably needs some of the
animation and additional 3D capabilities most readily obtained from
the Flash environment, I expect to need that integration. For those
reasons, and since the Earth api, as far as I can find, is scarcely
documented outside of Google's labs, and since the Map api, at this
time, does not include Street View, the code I am writing tests both
Javascript and Actionscript via your Flash api where it exists, or via
ExternalInterface, where it does not.]
Since there is more information that I can uncover in the Map groups,
I have worked more on that aspect for the last 24 hours. I am at the
point where I think I can say that there appears to be no generally
valid way to take the results from a geocode query based on a street
address, and computationally determine the correct yaw for a LookAt
that address from the 'nearest' Street View.
I seem to find that anyone who has posted a 'solution' for any
application making a similar request has had to resort to somehow
obtaining independent LatLon references points for the desired LookAt
targets. Some report using other geocode sources than you provide,
others report just performing some manual entry into some database
after manual investigation and refinement of the data from your
geocode sources. The nice demos to which you refer, in fact, all have
that dependency. If it is ok to ask the user to move a pointing
device -- a couple of feet up, a couple of feet down, a couple of feet
left, a couple of feet right -- the results of an atan2 function call
can yield the right answer. The question is how to get the right
answer when there is no operator intervention -- when it really is a
software-guided tour, and when most of what is generally known is the
ordinary address of some residence or business establishment and there
is no user hinting at the correct azimuth angle.
So, coupling that with what you have suggested, it seems that any
solution, given the presently available data, requires a database that
can yield the correct LookAt between two know points. Let's assume
that we make that investment in data collection. That, then, focuses
the effort on the animated visual effects of moving from one 'scene'
to another 'scene'. What is your recommendation in terms of the
direction of the Map and Earth aps? I think many folks could benefit
from a small planning matrix.
Take two 'size points': Applications very needful of a small resource
footprint, and applications for which resources -- be they network or
workstation are not a problem.
Take two 'apis': Map and Earth.
In the four cells, what's the recommended development direction for
RIAs that have the common characteristic of a user experience that can
be called a 'tour', by which I think I just mean, that [as contrasted
with a transaction], the user is primarily just sitting back and
watching and listening as the tour plays its natural course from start
to finish.
The nice thing about the current Earth integration of a Street View is
that the person creating the guided tour actually solves the problem
-- very precisely. If that snapshot set of attributes were correctly
captured, we would have what we need at playback time. It is actually
far superior to use the Earth UI to capture the complete orientation
-- including, where helpful, both zoom and tilt. The demos from the
Map api -- coming from a 2D world -- don't even address those two
additional attributes.
Sitting way outside your labs [though I can ride my bike down the
Guadalupe bike trail to get to your towers from Campbell], it sure
seems like the easiest, quickest, best fix would be to use the Earth
part of your toolkit to fix the missing KML data model.
tcorbet
Jul 26, 2008, 6:07:16 PM7/26/08
to KML Developer Support - Google Earth Browser Plugin
My apologies to you and Mano and Pamela and Barry -- all names that I
see intimately associated with parts of a large set of apis that
seemingly have different origins, different development teams, and
different Groups. I am going to hope that yours is the forum where
someone can try to express a request for resolving issues that
probably span different organizations inside Google, but, to us in the
outside world, really just appear as Google, Incorporated. Heck, in
the 80s we tried to reconcile parts of our computer-communications
playgrounds with Japan, Incorporated. I don't think you guys have
become that large yet. If you have, you really ought to have Eric
give some thought to creating a Ministry of International Trade and
Industry [MITI] to consolidate your efforts.
Ok, with another full day of searching every Group and every keyword
that seems related, I guess I have an inkling of what I should be
requesting to add to that Page that you are maintaining called "earth-
api-feature-request-page".
In the terminology of the "Google Earth COM API, I guess it boils down
to whether or not Google is planning to provide the functionality of
the ITourControllerGE in its Javascript [and then Actionscript] api so
that those of us with no COM framework skills or tools will be able to
exercise the full potential of Google Earth.
I am not expecting a commitment; I am just hoping for guidance. As
you succinctly summarized, recreating all of that would be a
considerable undertaking. I am less concerned about the amount of
effort than the fact that it seems so unnecessary. You guys --
collectively -- are the keepers of the keys to the kingdom. With the
right, slight tweeking of the KML of a 'snapshot', with the right
loading of an 'eternal KML' database into the plug-in, and with the
right animation primitives in the api, it would be very possible to
create Rich Internet Applications that include the behavior of the
Street View as multiple 'stops along the way' to a geodesy tour of
some part of the planet. Can we get any sort of "Statement of
Direction" from which we can try to make good decisions concerning
which toolkits from which vendors we should bet on?
Thank you -- all of you, as well as Mike Williams who seems to have
his arms around as much of this as is humanly possible.
On Jul 24, 12:56 pm, Roman N wrote:
> tcorbet,
>
> The inability to store the default view location within PhotoOverlays,
> which are used to store Street View panoramas, is a limitation in the
> KML specification. Also, the Earth API does not fully support
> PhotoOverlays yet.
>
> You could store a placemark (marker) for each Street View panorama
> that would serve as a 'look at' location. The Maps API Demo Gallery
> has a great example on how to make a Street View window look at a
> given point:http://gmaps-samples.googlecode.com/svn/trunk/streetview/angletowards....
see intimately associated with parts of a large set of apis that
seemingly have different origins, different development teams, and
different Groups. I am going to hope that yours is the forum where
someone can try to express a request for resolving issues that
probably span different organizations inside Google, but, to us in the
outside world, really just appear as Google, Incorporated. Heck, in
the 80s we tried to reconcile parts of our computer-communications
playgrounds with Japan, Incorporated. I don't think you guys have
become that large yet. If you have, you really ought to have Eric
give some thought to creating a Ministry of International Trade and
Industry [MITI] to consolidate your efforts.
Ok, with another full day of searching every Group and every keyword
that seems related, I guess I have an inkling of what I should be
requesting to add to that Page that you are maintaining called "earth-
api-feature-request-page".
In the terminology of the "Google Earth COM API, I guess it boils down
to whether or not Google is planning to provide the functionality of
the ITourControllerGE in its Javascript [and then Actionscript] api so
that those of us with no COM framework skills or tools will be able to
exercise the full potential of Google Earth.
I am not expecting a commitment; I am just hoping for guidance. As
you succinctly summarized, recreating all of that would be a
considerable undertaking. I am less concerned about the amount of
effort than the fact that it seems so unnecessary. You guys --
collectively -- are the keepers of the keys to the kingdom. With the
right, slight tweeking of the KML of a 'snapshot', with the right
loading of an 'eternal KML' database into the plug-in, and with the
right animation primitives in the api, it would be very possible to
create Rich Internet Applications that include the behavior of the
Street View as multiple 'stops along the way' to a geodesy tour of
some part of the planet. Can we get any sort of "Statement of
Direction" from which we can try to make good decisions concerning
which toolkits from which vendors we should bet on?
Thank you -- all of you, as well as Mike Williams who seems to have
his arms around as much of this as is humanly possible.
On Jul 24, 12:56 pm, Roman N wrote:
> tcorbet,
>
> The inability to store the default view location within PhotoOverlays,
> which are used to store Street View panoramas, is a limitation in the
> KML specification. Also, the Earth API does not fully support
> PhotoOverlays yet.
>
> You could store a placemark (marker) for each Street View panorama
> that would serve as a 'look at' location. The Maps API Demo Gallery
> has a great example on how to make a Street View window look at a
> I would also recommend checking out the other Street View related
> examples athttp://code.google.com/apis/maps/documentation/demogallery.html?searc....
>
> To simulate a tour of multiple locations, you could pull the list of
> tour stops from your KML file by using GXml from the Maps API (http://
> code.google.com/apis/maps/documentation/reference.html#GXml) and use
> some basic JavaScript to pan to the different locations.
>
> This is a fairly complex solution, requiring a fair amount of
> JavaScript knowledge. If you'd like to go this route, definitely start
> with some of the samples available at the Maps API Demo Gallery I
> mentioned before. And for more help, check out the Maps API group athttp://groups.google.com/group/Google-Maps-API. If you plan on using
> To simulate a tour of multiple locations, you could pull the list of
> tour stops from your KML file by using GXml from the Maps API (http://
> code.google.com/apis/maps/documentation/reference.html#GXml) and use
> some basic JavaScript to pan to the different locations.
>
> This is a fairly complex solution, requiring a fair amount of
> JavaScript knowledge. If you'd like to go this route, definitely start
> with some of the samples available at the Maps API Demo Gallery I
Roman N
Jul 28, 2008, 4:45:49 PM7/28/08
to KML Developer Support - Google Earth Browser Plugin
Firstly, I'd like to thank you for the enthusiasm with which you've
researched and used our APIs; the Geo APIs team are always glad to see
developers getting as much out of the Geo APIs as possible.
I want to preface by saying that the Earth API as well as the
documentation, tools, and samples are under very active development.
Many of the features you are alluding to may very well be implemented
in the future. However, Google does not release specific plans or
dates regarding new features and bug fixes. We do our best to provide
general guidance as well as ideas for temporary solutions. Our team
also requests that developers post their specific Feature Requests at
http://groups.google.com/group/kml-support/web/earth-api-feature-request-page,
as we check this page regularly to get a picture of which features are
most important for our product roadmap.
Here are some of my thoughts on your specific concerns:
...
can you be more specific? The JavaScript Maps API has substantial
demos on Street View integration (see previous links).
> Since there is more information that I can uncover in the Map groups,
> I have worked more on that aspect for the last 24 hours. I am at the
> point where I think I can say that there appears to be no generally
> valid way to take the results from a geocode query based on a street
> address, and computationally determine the correct yaw for a LookAt
> that address from the 'nearest' Street View.
Geocode queries are as precise as our data allows. It goes without
mention that we are perpetually upgrading our quality of results. As
for a yaw formula, the sample I linked before (http://gmaps-
samples.googlecode.com/svn/trunk/streetview/angletowardsbuilding.html)
contains a rough formula; you can also try one found at
http://mathforum.org/library/drmath/view/55417.html:
tc1=mod(atan2(sin(lon2-lon1)*cos(lat2),
cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon2-lon1)),
2*pi)
lon1 = longitude of point A
lat1 = latitude of point A
lon2 = longitude of point B
lat2 = latitude of point B
tc1 = direction of point B from point A (angle east of north)
If I have misinterpreted your question here, please elaborate.
...
realm of visual effects; that doesn't mean there won't be innovation
in that area. The Earth API does, however, provide for such transition
effects via SetAbstractView's smooth flying behavior. However, the
Earth API doesn't yet fully support KML's PhotoOverlay element, which
is how Google Earth implements Street View. We are working on this as
well as full KML support.
As I mentioned before, I can only provide some guidance, not a
specific plan for feature releases. I would recommend that developers
use both APIs as needed to achieve the desired effect. It is up to the
application developer to control the user experience. I would also
recommend practicing design flexibility since the Earth API is growing
quickly.
With regards to KML, it is now an open standard (see
http://www.opengeospatial.org/standards/kml). Although Google is a key
player in the KML community, the features and changes that go into the
KML spec are, in the end, up to the OGC.
> In the terminology of the "Google Earth COM API, I guess it boils down
> to whether or not Google is planning to provide the functionality of
> the ITourControllerGE in its Javascript [and then Actionscript] api so
> that those of us with no COM framework skills or tools will be able to
> exercise the full potential of Google Earth.
>
> I am not expecting a commitment; I am just hoping for guidance. As
> you succinctly summarized, recreating all of that would be a
> considerable undertaking. I am less concerned about the amount of
> effort than the fact that it seems so unnecessary. You guys --
> collectively -- are the keepers of the keys to the kingdom. With the
> right, slight tweeking of the KML of a 'snapshot', with the right
> loading of an 'eternal KML' database into the plug-in, and with the
> right animation primitives in the api, it would be very possible to
> create Rich Internet Applications that include the behavior of the
> Street View as multiple 'stops along the way' to a geodesy tour of
> some part of the planet. Can we get any sort of "Statement of
> Direction" from which we can try to make good decisions concerning
> which toolkits from which vendors we should bet on?
These are great ideas; again, I'd suggest posting to the Feature
Requests page.
We also encourage the development of third party libraries and
samples, such as those that we've seen written for the Maps API. We
often link to such efforts in our groups as well as in the Geo
Developers Blog at http://googlegeodevelopers.blogspot.com/. If you
have specific ideas about online tour implementations and want to
initiate an external developer effort, I think others would be happy
to participate.
Thanks again for a great discussion and I hope that it leads to
something great. When it does, do post a link!
- Roman
researched and used our APIs; the Geo APIs team are always glad to see
developers getting as much out of the Geo APIs as possible.
I want to preface by saying that the Earth API as well as the
documentation, tools, and samples are under very active development.
Many of the features you are alluding to may very well be implemented
in the future. However, Google does not release specific plans or
dates regarding new features and bug fixes. We do our best to provide
general guidance as well as ideas for temporary solutions. Our team
also requests that developers post their specific Feature Requests at
http://groups.google.com/group/kml-support/web/earth-api-feature-request-page,
as we check this page regularly to get a picture of which features are
most important for our product roadmap.
Here are some of my thoughts on your specific concerns:
...
> documented outside of Google's labs, and since the Map api, at this
> time, does not include Street View, the code I am writing tests both
> Javascript and Actionscript via your Flash api where it exists, or via
> ExternalInterface, where it does not.]
I'm unsure of what you mean by the Maps API not including Street View--
> time, does not include Street View, the code I am writing tests both
> Javascript and Actionscript via your Flash api where it exists, or via
> ExternalInterface, where it does not.]
can you be more specific? The JavaScript Maps API has substantial
demos on Street View integration (see previous links).
> Since there is more information that I can uncover in the Map groups,
> I have worked more on that aspect for the last 24 hours. I am at the
> point where I think I can say that there appears to be no generally
> valid way to take the results from a geocode query based on a street
> address, and computationally determine the correct yaw for a LookAt
> that address from the 'nearest' Street View.
mention that we are perpetually upgrading our quality of results. As
for a yaw formula, the sample I linked before (http://gmaps-
samples.googlecode.com/svn/trunk/streetview/angletowardsbuilding.html)
contains a rough formula; you can also try one found at
http://mathforum.org/library/drmath/view/55417.html:
tc1=mod(atan2(sin(lon2-lon1)*cos(lat2),
cos(lat1)*sin(lat2)-sin(lat1)*cos(lat2)*cos(lon2-lon1)),
2*pi)
lon1 = longitude of point A
lat1 = latitude of point A
lon2 = longitude of point B
lat2 = latitude of point B
tc1 = direction of point B from point A (angle east of north)
If I have misinterpreted your question here, please elaborate.
...
> the effort on the animated visual effects of moving from one 'scene'
> to another 'scene'. What is your recommendation in terms of the
> direction of the Map and Earth aps? I think many folks could benefit
> from a small planning matrix.
>
> to another 'scene'. What is your recommendation in terms of the
> direction of the Map and Earth aps? I think many folks could benefit
> from a small planning matrix.
>
> The nice thing about the current Earth integration of a Street View is
> that the person creating the guided tour actually solves the problem
> -- very precisely. If that snapshot set of attributes were correctly
> captured, we would have what we need at playback time. It is actually
> far superior to use the Earth UI to capture the complete orientation
> -- including, where helpful, both zoom and tilt. The demos from the
> Map api -- coming from a 2D world -- don't even address those two
> additional attributes.
>
> Sitting way outside your labs [though I can ride my bike down the
> Guadalupe bike trail to get to your towers from Campbell], it sure
> seems like the easiest, quickest, best fix would be to use the Earth
> part of your toolkit to fix the missing KML data model.
As you probably know, Street View doesn't currently do much in the
> that the person creating the guided tour actually solves the problem
> -- very precisely. If that snapshot set of attributes were correctly
> captured, we would have what we need at playback time. It is actually
> far superior to use the Earth UI to capture the complete orientation
> -- including, where helpful, both zoom and tilt. The demos from the
> Map api -- coming from a 2D world -- don't even address those two
> additional attributes.
>
> Sitting way outside your labs [though I can ride my bike down the
> Guadalupe bike trail to get to your towers from Campbell], it sure
> seems like the easiest, quickest, best fix would be to use the Earth
> part of your toolkit to fix the missing KML data model.
realm of visual effects; that doesn't mean there won't be innovation
in that area. The Earth API does, however, provide for such transition
effects via SetAbstractView's smooth flying behavior. However, the
Earth API doesn't yet fully support KML's PhotoOverlay element, which
is how Google Earth implements Street View. We are working on this as
well as full KML support.
As I mentioned before, I can only provide some guidance, not a
specific plan for feature releases. I would recommend that developers
use both APIs as needed to achieve the desired effect. It is up to the
application developer to control the user experience. I would also
recommend practicing design flexibility since the Earth API is growing
quickly.
With regards to KML, it is now an open standard (see
http://www.opengeospatial.org/standards/kml). Although Google is a key
player in the KML community, the features and changes that go into the
KML spec are, in the end, up to the OGC.
> In the terminology of the "Google Earth COM API, I guess it boils down
> to whether or not Google is planning to provide the functionality of
> the ITourControllerGE in its Javascript [and then Actionscript] api so
> that those of us with no COM framework skills or tools will be able to
> exercise the full potential of Google Earth.
>
> I am not expecting a commitment; I am just hoping for guidance. As
> you succinctly summarized, recreating all of that would be a
> considerable undertaking. I am less concerned about the amount of
> effort than the fact that it seems so unnecessary. You guys --
> collectively -- are the keepers of the keys to the kingdom. With the
> right, slight tweeking of the KML of a 'snapshot', with the right
> loading of an 'eternal KML' database into the plug-in, and with the
> right animation primitives in the api, it would be very possible to
> create Rich Internet Applications that include the behavior of the
> Street View as multiple 'stops along the way' to a geodesy tour of
> some part of the planet. Can we get any sort of "Statement of
> Direction" from which we can try to make good decisions concerning
> which toolkits from which vendors we should bet on?
Requests page.
We also encourage the development of third party libraries and
samples, such as those that we've seen written for the Maps API. We
often link to such efforts in our groups as well as in the Geo
Developers Blog at http://googlegeodevelopers.blogspot.com/. If you
have specific ideas about online tour implementations and want to
initiate an external developer effort, I think others would be happy
to participate.
Thanks again for a great discussion and I hope that it leads to
something great. When it does, do post a link!
- Roman
tcorbet
Jul 29, 2008, 3:19:27 AM7/29/08
to KML Developer Support - Google Earth Browser Plugin, pamel...@gmail.com
01. Sorry for a poorly-crafted statement: The Map api which does not
include Street View is the Flash/Actionscript version of the Map api.
As you have noted, the Javascript-base Map api does a very good job of
documenting some of the key matters pertaining to the Street View
feature.
02. The problem of programmatically calculating the yaw from a Street
View to a specific location is an extensive topic that I have tried to
cover under the "Google Maps API" Group. I do believe, Roman, that
beyond my not-so-good joke about Google, INC. as analogous to Japan,
INC., there is an important action item. The current
compartmentalization of topics in multiple Groups is not as efficient
-- for either you guys or for us -- as it ought to be. Anything done
to step back and spend some time on infrastructures for 'issue
reporting -- code bug reporting, documentation bug reporting, tutorial
examples, enhancement request, release management -- would be time and
talent well spent.
Specifically, I have developed a demo program that can be helpful for
understanding why none of the algorithms variously recommended seems
to be able to successfully solve the problem of being able to reliably
construct the PoV attributes. I have, on the other thread, asked
Pamela to share the information with you for whatever value it may
have. -- for whatever destination Group would be best for sharing the
information. It includes a variation on the algorithm that you have
included here, that does have a higher success rate than that one, but
the bottom line is that every case where I have found someone who has
solved the problem, the solution has required either the use of a
different database of geocoded establishments/residences or operator
intervention to 'tweek' the PoV.
The tie-in, then, as far as I understand your organization, and
directions of development is that you already have in the Google Earth
application a perfectly good User Interface for performing the
operator intervention to 'tweek' the PoV. It only remains to make
sure that the results of that user interaction can be seamlessly
passed to the Map/GE apis via the KML.
03. I think that really only leaves animation. I did not try to use
your 'open document' to post a request for enhancement that would take
on most of the capabilities and behaviors that exist in the C++/COM
api under the ITourController part of the code. I only hope that my
simple suggestion, based, no doubt, on a tremendous lack of
understanding of the details or effort, can be put on the table for
consideration even if I cannot figure out how to make a product
proposal via the 'enhancement sheet' you are maintaining.
As someone who has spent a lot of time on the Sandy, Papervision and
Away3D lists, let me just offer the opinion that for as much as we
love all the 3D capabilities we can simulate with those libraries, it
really is hard to accomplish the spherical camera navigation to equal
the 'fly in' effects that folks have come to expect from a GE
experience. The Flash 10 Player is almost ready for production
release, and the Actionscript equivalent of the ITourController
behaviors ought to be very impressive on a small code footprint.
Thanks for your response and interest. I think I need to shut up and
go write some code.
include Street View is the Flash/Actionscript version of the Map api.
As you have noted, the Javascript-base Map api does a very good job of
documenting some of the key matters pertaining to the Street View
feature.
02. The problem of programmatically calculating the yaw from a Street
View to a specific location is an extensive topic that I have tried to
cover under the "Google Maps API" Group. I do believe, Roman, that
beyond my not-so-good joke about Google, INC. as analogous to Japan,
INC., there is an important action item. The current
compartmentalization of topics in multiple Groups is not as efficient
-- for either you guys or for us -- as it ought to be. Anything done
to step back and spend some time on infrastructures for 'issue
reporting -- code bug reporting, documentation bug reporting, tutorial
examples, enhancement request, release management -- would be time and
talent well spent.
Specifically, I have developed a demo program that can be helpful for
understanding why none of the algorithms variously recommended seems
to be able to successfully solve the problem of being able to reliably
construct the PoV attributes. I have, on the other thread, asked
Pamela to share the information with you for whatever value it may
have. -- for whatever destination Group would be best for sharing the
information. It includes a variation on the algorithm that you have
included here, that does have a higher success rate than that one, but
the bottom line is that every case where I have found someone who has
solved the problem, the solution has required either the use of a
different database of geocoded establishments/residences or operator
intervention to 'tweek' the PoV.
The tie-in, then, as far as I understand your organization, and
directions of development is that you already have in the Google Earth
application a perfectly good User Interface for performing the
operator intervention to 'tweek' the PoV. It only remains to make
sure that the results of that user interaction can be seamlessly
passed to the Map/GE apis via the KML.
03. I think that really only leaves animation. I did not try to use
your 'open document' to post a request for enhancement that would take
on most of the capabilities and behaviors that exist in the C++/COM
api under the ITourController part of the code. I only hope that my
simple suggestion, based, no doubt, on a tremendous lack of
understanding of the details or effort, can be put on the table for
consideration even if I cannot figure out how to make a product
proposal via the 'enhancement sheet' you are maintaining.
As someone who has spent a lot of time on the Sandy, Papervision and
Away3D lists, let me just offer the opinion that for as much as we
love all the 3D capabilities we can simulate with those libraries, it
really is hard to accomplish the spherical camera navigation to equal
the 'fly in' effects that folks have come to expect from a GE
experience. The Flash 10 Player is almost ready for production
release, and the Actionscript equivalent of the ITourController
behaviors ought to be very impressive on a small code footprint.
Thanks for your response and interest. I think I need to shut up and
go write some code.
Roman N
Jul 30, 2008, 11:57:21 AM7/30/08
to KML Developer Support - Google Earth Browser Plugin
> 02. The problem of programmatically calculating the yaw from a Street
> View to a specific location is an extensive topic that I have tried to
> cover under the "Google Maps API" Group. I do believe, Roman, that
> beyond my not-so-good joke about Google, INC. as analogous to Japan,
> INC., there is an important action item. The current
> compartmentalization of topics in multiple Groups is not as efficient
> -- for either you guys or for us -- as it ought to be. Anything done
> to step back and spend some time on infrastructures for 'issue
> reporting -- code bug reporting, documentation bug reporting, tutorial
> examples, enhancement request, release management -- would be time and
> talent well spent.
as their documentation, reporting tools, samples, etc. are under
active development; developer workflow is always under consideration.
> Specifically, I have developed a demo program that can be helpful for
> understanding why none of the algorithms variously recommended seems
> to be able to successfully solve the problem of being able to reliably
> construct the PoV attributes. I have, on the other thread, asked
> Pamela to share the information with you for whatever value it may
> have. -- for whatever destination Group would be best for sharing the
> information. It includes a variation on the algorithm that you have
> included here, that does have a higher success rate than that one, but
> the bottom line is that every case where I have found someone who has
> solved the problem, the solution has required either the use of a
> different database of geocoded establishments/residences or operator
> intervention to 'tweek' the PoV.
starting point for other developers to find more accurate solutions.
Also, if Google's geocoding mechanism is inaccurate, please feel free
to report it at http://earth.google.com/support/bin/answer.py?hl=en&answer=21454.
We value the quality of our service tremendously and are thus
constantly improving it. In the case that it fails to meet your
specific business needs, you are completely free to use other
providers.
>
> 03. I think that really only leaves animation. I did not try to use
> your 'open document' to post a request for enhancement that would take
> on most of the capabilities and behaviors that exist in the C++/COM
> api under the ITourController part of the code. I only hope that my
> simple suggestion, based, no doubt, on a tremendous lack of
> understanding of the details or effort, can be put on the table for
> consideration even if I cannot figure out how to make a product
> proposal via the 'enhancement sheet' you are maintaining.
through this page; feature requests can be as broad or specific as
you'd like. If you are having trouble physically adding your feature
requests, please let me know what specifically is going wrong.
>
> As someone who has spent a lot of time on the Sandy, Papervision and
> Away3D lists, let me just offer the opinion that for as much as we
> love all the 3D capabilities we can simulate with those libraries, it
> really is hard to accomplish the spherical camera navigation to equal
> the 'fly in' effects that folks have come to expect from a GE
> experience. The Flash 10 Player is almost ready for production
> release, and the Actionscript equivalent of the ITourController
> behaviors ought to be very impressive on a small code footprint.
should be an exciting release for developers and end users alike.
Thanks,
- Roman
Reply all
Reply to author
Forward
0 new messages