3 ms·

Stripe for location – easily build geospatial data into your apps and models

86 points by secatanzaro 5y ago

itsovermyhead 5y ago
I'm looking forward to trying this out and building something with this! It looks like they're aggregating data from OSM: https://data.iggy.cloud/datasets https://data.iggy.cloud/datasets That's quite exciting. Having worked extensively with OSM and trying to build something useful out of their data, it's historically been a huge pain to do. I'm more than happy to pay them to make my life easier. I'm interested in seeing how they add new and interesting datasets. I expect there's going to be some difficulty with keeping things interesting and useful, while making sure it's still simple.
- lpetting 5y ago
  You're right that there's a ton of OSM data that most people can't use. We want to change that and give access to so much more. Follow us on Twitter at https://mobile.twitter.com/askiggyapp https://mobile.twitter.com/askiggyapp for lots more code samples this week and demos to come!
leros 5y ago
Interesting. I work at a large tech company. We have an entire team that basically maintains something like this as an internal service.
- lpetting 5y ago
  For real. No reason w can't build it as a service! (I'm the CEO of Iggy)
lpetting 5y ago
Thanks for posting! I'm Lindsay, the CEO of Iggy. I was a Data Scientist at Airbnb for ~5 years and was shocked at how little we knew and leveraged about location in our product and models. I had done a lot of GIS work in grad school and knew it could be better, so I left last year to start Iggy. Turns out Airbnb wasn't the only company to struggle with this-- so many other cos in travel, real estate and insurance have trouble building, maintaining and leveraging geographic and location data. We've been working with a few in stealth, and are excited to now open up our APIs for broader use. I am happy to answer any questions folks may have. In the meantime: - check out our launch blog here: https://medium.com/iggy-tech/launching-iggy-self-serve-apis-93970d4ebbd1 https://medium.com/iggy-tech/launching-iggy-self-serve-apis-... - API ref: https://docs.askiggy.com/reference/features-1 https://docs.askiggy.com/reference/features-1 - follow us here: https://twitter.com/askiggyapp https://twitter.com/askiggyapp
mleonhard 5y ago
I am developing a dating app and will be adding a venue search function soon. I hope Iggy can provide the data for this with reasonable terms. Specifically, I want to pre-process the data, store it in a database, and use the app's backend to do search. Google Maps API [1], TomTom API [2], HERE API [3], Mapbox Geocoding API [4], Azure Maps [5], Yelp [6] and other mature geocoding APIs have licenses with extreme restrictions. They forbid storing any of their data. Apps are limited to the search APIs provided directly by the vendor's API. And since caching is forbidden, they carry the risk of unintentionally running up a huge bill. The vendor can suddenly raise the price (as Google Maps API already did once) and applications cannot use caching to reduce costs since that is forbidden by the terms. They require brand attribution. They forbid combining their data with data from other sources, like the app's users. They forbid showing their data on other maps. These limitations make the APIs mostly useless for innovative new applications. A few new API companies have few data restrictions. Radar [7] allows caching data for 30 days. Geoapify [8] allows saving data. What is Iggy's policy on saving and caching data returned from the API? I skimmed Iggy's Terms of Service [9] and found nothing about this. How fresh is Iggy's data for Points-of-Interest hours of operation? I'm mostly interested in osm_coffee_shops, osm_restaurants, and osm_bars. [1] https://cloud.google.com/maps-platform/terms https://cloud.google.com/maps-platform/terms [2] https://developer.tomtom.com/terms-and-conditions https://developer.tomtom.com/terms-and-conditions [3] https://developer.here.com/terms-and-conditions#restrictions-on-here-materials https://developer.here.com/terms-and-conditions#restrictions... [4] https://docs.mapbox.com/api/search/geocoding/ https://docs.mapbox.com/api/search/geocoding/ [5] https://docs.microsoft.com/en-us/answers/questions/214472/azure-maps-cahcing-policy.html https://docs.microsoft.com/en-us/answers/questions/214472/az... [6] https://www.yelp.com/developers/api_terms https://www.yelp.com/developers/api_terms [7] https://radar.io/terms https://radar.io/terms [8] https://www.geoapify.com/term-and-conditions https://www.geoapify.com/term-and-conditions [9] https://www.askiggy.com/terms https://www.askiggy.com/terms
- acocos 5y ago
  Our osm POI data currently reflects osm as of Jul 7, and we're working on figuring out the best cadence to update it. Of course the underlying osm data has its own sporadic update frequency. Maybe Iggy could be part of a feedback loop for finding stale osm data? (I do data science at Iggy).

86 points by secatanzaro 5y ago

I'm looking forward to trying this out and building something with this! It looks like they're aggregating data from OSM: https://data.iggy.cloud/datasets https://data.iggy.cloud/datasets That's quite exciting. Having worked extensively with OSM and trying to build something useful out of their data, it's historically been a huge pain to do. I'm more than happy to pay them to make my life easier. I'm interested in seeing how they add new and interesting datasets. I expect there's going to be some difficulty with keeping things interesting and useful, while making sure it's still simple.

lpetting 5y ago
You're right that there's a ton of OSM data that most people can't use. We want to change that and give access to so much more. Follow us on Twitter at https://mobile.twitter.com/askiggyapp https://mobile.twitter.com/askiggyapp for lots more code samples this week and demos to come!

leros 5y ago

Interesting. I work at a large tech company. We have an entire team that basically maintains something like this as an internal service.

lpetting 5y ago
For real. No reason w can't build it as a service! (I'm the CEO of Iggy)

lpetting 5y ago

Thanks for posting! I'm Lindsay, the CEO of Iggy. I was a Data Scientist at Airbnb for ~5 years and was shocked at how little we knew and leveraged about location in our product and models. I had done a lot of GIS work in grad school and knew it could be better, so I left last year to start Iggy. Turns out Airbnb wasn't the only company to struggle with this-- so many other cos in travel, real estate and insurance have trouble building, maintaining and leveraging geographic and location data. We've been working with a few in stealth, and are excited to now open up our APIs for broader use. I am happy to answer any questions folks may have. In the meantime: - check out our launch blog here: https://medium.com/iggy-tech/launching-iggy-self-serve-apis-93970d4ebbd1 https://medium.com/iggy-tech/launching-iggy-self-serve-apis-... - API ref: https://docs.askiggy.com/reference/features-1 https://docs.askiggy.com/reference/features-1 - follow us here: https://twitter.com/askiggyapp https://twitter.com/askiggyapp

mleonhard 5y ago

I am developing a dating app and will be adding a venue search function soon. I hope Iggy can provide the data for this with reasonable terms. Specifically, I want to pre-process the data, store it in a database, and use the app's backend to do search. Google Maps API [1], TomTom API [2], HERE API [3], Mapbox Geocoding API [4], Azure Maps [5], Yelp [6] and other mature geocoding APIs have licenses with extreme restrictions. They forbid storing any of their data. Apps are limited to the search APIs provided directly by the vendor's API. And since caching is forbidden, they carry the risk of unintentionally running up a huge bill. The vendor can suddenly raise the price (as Google Maps API already did once) and applications cannot use caching to reduce costs since that is forbidden by the terms. They require brand attribution. They forbid combining their data with data from other sources, like the app's users. They forbid showing their data on other maps. These limitations make the APIs mostly useless for innovative new applications. A few new API companies have few data restrictions. Radar [7] allows caching data for 30 days. Geoapify [8] allows saving data. What is Iggy's policy on saving and caching data returned from the API? I skimmed Iggy's Terms of Service [9] and found nothing about this. How fresh is Iggy's data for Points-of-Interest hours of operation? I'm mostly interested in osm_coffee_shops, osm_restaurants, and osm_bars. [1] https://cloud.google.com/maps-platform/terms https://cloud.google.com/maps-platform/terms [2] https://developer.tomtom.com/terms-and-conditions https://developer.tomtom.com/terms-and-conditions [3] https://developer.here.com/terms-and-conditions#restrictions-on-here-materials https://developer.here.com/terms-and-conditions#restrictions... [4] https://docs.mapbox.com/api/search/geocoding/ https://docs.mapbox.com/api/search/geocoding/ [5] https://docs.microsoft.com/en-us/answers/questions/214472/azure-maps-cahcing-policy.html https://docs.microsoft.com/en-us/answers/questions/214472/az... [6] https://www.yelp.com/developers/api_terms https://www.yelp.com/developers/api_terms [7] https://radar.io/terms https://radar.io/terms [8] https://www.geoapify.com/term-and-conditions https://www.geoapify.com/term-and-conditions [9] https://www.askiggy.com/terms https://www.askiggy.com/terms

acocos 5y ago
Our osm POI data currently reflects osm as of Jul 7, and we're working on figuring out the best cadence to update it. Of course the underlying osm data has its own sporadic update frequency. Maybe Iggy could be part of a feedback loop for finding stale osm data? (I do data science at Iggy).