30 replies to this topic

[Luke]

Why Yahoo maps? I'm assuming the map is a static jpeg? Is Google also an option? (Google has a static maps api)

[Matt]

I will explain more next week but rest assured I read both Yahoo and Google's TOC with mapping. The map on that page is actually dynamic and interactive.

Regarding Google, this was mostly the deal breaker:

Use of the Google Static Maps API is subject to a query limit of 1000 unique (different) image requests per viewer per day.

Unless of course you want to purchase a premium API key from Google. Yahoo! has no rate limit for its free key. We also use the Yahoo! API for reverse geo mapping which again Google had strict limits on.

[Luke]

I will explain more next week but rest assured I read both Yahoo and Google's TOC with mapping. The map on that page is actually dynamic and interactive.

Regarding Google, this was mostly the deal breaker:

Unless of course you want to purchase a premium API key from Google. Yahoo! has no rate limit for its free key. We also use the Yahoo! API for reverse geo mapping which again Google had strict limits on.

The v3 of the Google Maps API doesn't require an API key. I'm not sure if this limit still applies.. But if it does it applies to Geocoding (Physical Address -> Latitude, Longitude) and the user's IP Address. If using Javascript this means the limit applies to a single user. If using the server it applies to the server's IP address (where the problem would be).

This is for Goetagged photo's, correct? From what I understand these photo's already contain latitude and longitude coordinants, so there would be no need to Geocode. The dynamic map without geocoding doesn't have limits... If there is a limit with the static map itself... the result should be cached anyway.

The only time you'd have to Geocode an address is if a user physially typed in the address. Either way, for most of us, the limit won't be as bad, especially if the result is cached. It might be a problem for larger communities, and even if it is it just means it'll take a little more time to get the resulting map (worse case).

Could you make it an option (admin)? Please ?

[Matt]

The v3 of the Google Maps API doesn't require an API key. I'm not sure if this limit still applies.. But if it does it applies to Geocoding (Physical Address -> Latitude, Longitude) and the user's IP Address. If using Javascript this means the limit applies to a single user. If using the server it applies to the server's IP address (where the problem would be).

This is for Goetagged photo's, correct? From what I understand these photo's already contain latitude and longitude coordinants, so there would be no need to Geocode. The dynamic map without geocoding doesn't have limits... If there is a limit with the static map itself... the result should be cached anyway.

The only time you'd have to Geocode an address is if a user physially typed in the address. Either way, for most of us, the limit won't be as bad, especially if the result is cached. It might be a problem for larger communities, and even if it is it just means it'll take a little more time to get the resulting map (worse case).

Could you make it an option (admin)? Please ?

Goodness me that is a lot of supposition for someone who has not seen the code or feature set. With all due respect I didn't just wander in bleary eyed and pick the first map I saw.

Even the v3 API has a rate limit. And I also reverse geocode to fetch the town name. Google only allow you to reverse geocode if you display it along with a google map. I intend to use the reverse geocode data elsewhere. And they limit access to that too. Yahoo does not.

I picked the best solution for our product. Ultimately it's just a map. I won't be adding admin options to integrate with google. That would be a waste of time and code.

Also, the Yahoo API key allows access to Flickr so we have options to integrate there also with the same key.

[Luke]

I didn't mean to offend you Matt. I was just offering my feedback. Personally I don't like the Yahoo Maps API. If this is about integration with Flickr, then I can understand. Please don't take this the wrong way.

I'm not asking you to use Google's Geocoding. I understand that could be quite a lot of work. At the very least it would be nice to choose which map to display. You can feed the same coordinates you obtained from Yahoo into a Google Map. Since there is no API key to obtain, this should be quite trivial. But if I am wrong, I do apologize.

I have worked with both map API's extensively. In most cases without thousands of markers on a single map. I have found Google Maps API much more accurate, easier to work with, and a lot faster. I have found Yahoo's API to be lacking. From what I've seen you're using a single marker on a single map, which I guess doesn't matter. But if you were to put all those markers on a single map I feel Google handles that better.

I didn't mean to step on any toes. I know the feedback I give is somewhat annoying at times, but I mean well.

[Matt]

No offense taken.

I realise it's hard to fully understand the integration without knowing the feature set of which I have deliberately withheld information.

My first integration was using Google maps static images, I took a screen cap here:



However, I decided that I wanted to store the actual city name, etc which meant doing a reverse geocode. I spent a good while scouring the TOC for Google Maps and was put off by a few things, including:

If more than 2,500 geocode requests in a 24 hour period are received from a single IP address, or geocode requests are submitted from a single IP address at too fast a rate, the Google Maps API geocoder will begin responding with a status code of 620

Now it's moderately unlikely that an average website will have more than 2500 geocoded uploads in a day but it is possible. Even more worrying is the "at too fast a rate" which is very nebulous and I could see some busy sites hitting that. Ultimately when something goes wrong, such as geo data not appearing we get a ticket about it and its our problem to fix. The IP would be from the server so it would be from a single IP address.

The final nail was:

...and note that use of the geocoder for any purpose other than obtaining locations that will be displayed using the Google Maps APIs is a violation of the Terms of Service.

Now, if at some point we wanted to have a feature that allowed you to list all photos in one place or display a list of places used in an album, that technically violates that specific TOS.

Regarding mapping, I did consider caching the Google image, but again Google prohibits that:

You may not store and serve copies of images generated using the Google Static Maps API from your website.

As you can see, I did not take the decision lightly. Yahoo just offered a very similar service but without the restrictions.

[Luke]

You may not store and serve copies of images generated using the Google Static Maps API from your website.

That's the first I've heard of that . I know of a lot of websites that actually do this, and to me it would make sense to cache the image when the address itself doesn't change... You're right, that is ridiculous!

Would it be possible to do all the Geocoding with Yahoo behind the scenes and simply display Google Map (as an option), or is there more to it? (Yes/No?)

[mikesound]

regarding the map feature

while its great to see it being added to the gallery

will it be a gallery only specific feature

or are there plans to make it a core feature ?

ie allow any content item to have lat, long and location title properties

and so then can use it for "modules" such as gallery but also calendar, members, articles,
and ipcontent

[ZakRhyno]

Now their should be a feature that turns this mapping system off or no. Also maybe make it per album or per image for the reason that maps don't worry for every community type and working with many then just social focus should be a key here.

[Matt]

regarding the map feature

while its great to see it being added to the gallery

will it be a gallery only specific feature

or are there plans to make it a core feature ?

ie allow any content item to have lat, long and location title properties

and so then can use it for "modules" such as gallery but also calendar, members, articles,
and ipcontent

Not in the first release. Until geocoding is more widely used at least.

Now their should be a feature that turns this mapping system off or no. Also maybe make it per album or per image for the reason that maps don't worry for every community type and working with many then just social focus should be a key here.

You have to implicitly enable the map for each image. You can do this during the 'review' stage of the upload process.

[mikesound]

Not in the first release. Until geocoding is more widely used at least.



snipped

ah ok, thanks for the reply
dont really get why the dev of gallery and blog etc often takes on such a stand alone approach
as would have thought a more modular approach would have many advantages
but guess there are reasons
thanks

[Matt]

Where else would you use mapping? Other than user's location? And even then it would require manual input so one imagines it wouldn't get that much population. I certainly wouldn't want my home address being disclosed.

Sometimes you have to ask the "why" along with the "can we?".

[mikesound]

Where else would you use mapping? Other than user's location? And even then it would require manual input so one imagines it wouldn't get that much population. I certainly wouldn't want my home address being disclosed.

Sometimes you have to ask the "why" along with the "can we?".

i would say that by adding it to core and opening it up to all invision modules it could offer a extra dimension to all invision products
not only can you then offer content based on locations
but you can then also offer content based on the individual user location


i use a modded version of the members map mod
to offer location mapping in the calendar for a event guide
each event entered can have a dynamic google map and a rotating streep map view on its own page

but once the info is entered can then also offer different dynamic map views
eg a dynamic map view of all events in next week, next month and so on

if you then add the members locations into it
it then opens it right up
eg a site could display all events within 50km of the member viewing location and so on

could do the same with the gallery
eg once have the locations entered could offer a map view
which could open it up to many uses
or could use the info for more tradiotional views

they are the most obvious uses, but once you do have a location reference for a item of content and the location of member
you could use this for any of the invision modules

as in a site could offer content based on the members locations
and also vice versa
be it displayed via traditional methods or via dynamic map or similar views

dont get me wrong its great to see it getting added to the gallery
just feel it could offer a extra dimension to the other modules as well

[Kyanar]

I will explain more next week but rest assured I read both Yahoo and Google's TOC with mapping. The map on that page is actually dynamic and interactive.

Regarding Google, this was mostly the deal breaker:



Unless of course you want to purchase a premium API key from Google. Yahoo! has no rate limit for its free key. We also use the Yahoo! API for reverse geo mapping which again Google had strict limits on.

You are actually incorrect good sir. Although the limit is high enough that you will likely never hit it, the Yahoo limits are actually 50,000 requests per day. Bing's is a solid option too (and it would be a good option, since those of us inextricably tied with Microsoft generally have access to the enterprise offering already).

Also, reading the Yahoo Maps API terms reveals the following gems, which this thread seems to imply you'd missed:

1. Geocoding for any purpose other than displaying on a Yahoo map is forbidden.
2. Use any data less than 6 hours old (i.e. you'll have to block geocoding of any photo that was recently taken)
3. Cache or otherwise store the maps (nope, you have to request them again every time!)
4. And there's a bizarre clause that reads to me like you're not allowed to display any geocoded information at all, ever.

[Matt]

I'm aware of those items.

I like the separation of Yahoo in that you (board admin) have to request an API key so it removes us (IPS) as the API provider which negates a lot of the "non-commercial' clauses.

Essentially most of the TOC is to prevent someone from building a "sat nav" application or from profiteering from their data. They have a "contact us for clarification/permission" form which I've made us of and hope to hear back clarifying the finer points.

I am very confident that they will clarify those points for me.

[Matt]

After much deliberation:

- I have scoured Bing's TOC and I must admit they are much less restrictive. They allow local caching of data and are less concerned in general in how you access and store the information. They do have limits of 500,000 requests in a 12 month period but with caching of data this shouldn't be a huge problem. For these reasons, I have switched to Bing for the default mapping service.
- I have abstracted the mapping into IP.Board core and abstracted out the services into separate classes so you can write your own mapping plug ins to use Google, etc.

[Luke]

After much deliberation:

- I have scoured Bing's TOC and I must admit they are much less restrictive. They allow local caching of data and are less concerned in general in how you access and store the information. They do have limits of 500,000 requests in a 12 month period but with caching of data this shouldn't be a huge problem. For these reasons, I have switched to Bing for the default mapping service.
- I have abstracted the mapping into IP.Board core and abstracted out the services into separate classes so you can write your own mapping plug ins to use Google, etc.

Awesome, sounds great Matt

I'm sure someone in the community will make a Google module.

[Brandon D]

After much deliberation:

- I have scoured Bing's TOC and I must admit they are much less restrictive. They allow local caching of data and are less concerned in general in how you access and store the information. They do have limits of 500,000 requests in a 12 month period but with caching of data this shouldn't be a huge problem. For these reasons, I have switched to Bing for the default mapping service.
- I have abstracted the mapping into IP.Board core and abstracted out the services into separate classes so you can write your own mapping plug ins to use Google, etc.

+1

[Myr]

I was going to ask about Bing. I've been using them more and more.

[Matt]

I have written the Google Maps plug in for those that want it.

Includes: Map images and reverse geocoding using Google's APIs.