Right. The best you could do is some sort of “center” of the zip code, but they aren’t evenly shaped or similar sizes. 89049 is 10,000 square miles and 11109 is two blocks in NYC.
89049 is six disconnected areas. https://www.google.com/maps/place/Tonopah,+NV+89049/@38.51715,-116.8341002,9z/data=!4m5!3m4!1s0x80ba30d165da8f09:0xaf8f27eb9fd93664!8m2!3d38.3675335!4d-115.9467997 What does the current API do, exactly? wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Dec 14, 2022, at 9:37 AM, dmitri maziuk <dmitri.maz...@gmail.com> wrote: > > On 2022-12-14 10:45 AM, Matthew Castrigno wrote: >> Hi Gus, >> Thank you for your reply. I am trying to emulate an existing API that is why >> I am trying to work with the Zipcode directly. After looking at this it >> looks like I will have to do a few things. >> 1. When indexing I will need to index the location in a spatial field >> <fieldType name="location" class="solr.LatLonPointSpatialField" >> docValues="true"/> >> 2. Along with the zipcode (in case just a straight zipcode match is >> desired) I will have to lookup the GPS coordinates of the zipcode and pass >> them as the pt parameter. >> 3. Finally, I will need to use the functional query geodist() to return a >> field that will be the distance from the location in item 1 and the pt >> parameters in item 2. > > The point of the url I send earlier is that zipcodes are weird irregular > shapes that don't work well with regular spatial queries. I.e. there is no > such thing as "GPS coordinates of the zipcode" (#2). > > Dima >
