Stripe for location – easily build geospatial data into your apps and models | Hacker News Reader

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

askiggy.com

86 pointssecatanzaro10 comments

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-... - API ref: https://docs.askiggy.com/reference/features-1 - follow us here: https://twitter.com/askiggyapp

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

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.

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 for lots more code samples this week and demos to come!

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

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

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

[2] https://developer.tomtom.com/terms-and-conditions

[3] https://developer.here.com/terms-and-conditions#restrictions...

[4] https://docs.mapbox.com/api/search/geocoding/

[5] https://docs.microsoft.com/en-us/answers/questions/214472/az...

[6] https://www.yelp.com/developers/api_terms

[7] https://radar.io/terms

[8] https://www.geoapify.com/term-and-conditions

[9] https://www.askiggy.com/terms

The frustrations you mention are some of the primary reasons we started iggy. There's a lot to this so I'll respond to your concerns one by one.

- You can store our data for thirty days, and that can be extended to month-to-month as long as you have a subscription. (This is covered in the 'SERVICE.' section of our TOS) Just keep in mind it will get stale if not updated on some cadence. - Price: we are a new startup and inevitably have a lot to learn about pricing, but we will always communicate any pricing changes (This is covered in the "FEES AND PAYMENTS." Section of our TOS) - We do require attribution, and there are many ways to do this-- happy to chat more about options here. (This is covered in the "CUSTOMER RESPONSIBILITIES." Section of our TOS). To keep in mind, OSM data does come with a license that is still in effect if you are using it via our API. (osm attribution, and share alike when combined with other data, helpful info here: https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Lega...). - You can combine our data w other sources. (Why? Iggy is founded by engineers, data scientists and others who get that this is how data becomes useful.) - You can share our data on other maps unless otherwise specified (i.e. our datasets that start with 'licensed_'; see dataset-specific info in our data catalog (linked above))

Does that help? If you have any other questions about this please don't hesitate to reach out to me at lindsay@askiggy.com

Your response is helpful. Thank you.

I'm glad.

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).

Reply on news.ycombinator.com