Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We need to discuss IF and HOW Geolocation Field should store address information (either geocoded or entered by the user).
Google's geocoder for example returns *a lot* information (Try this demo). Here is an example, somewhere on La Rambla in Barcelona, Spain.
- Lat: 41.38131735079649
- Lng: 2.173009026050594
- street_number: 77
- route: La Rambla
- locality, political: Barcelona
- administrative_area_level_2, political: Province Barcelona
- administrative_area_level_1, political: Catalonia
- country, political: Spain
- postal_code: 08002
Google's geocoder is just one widget that helps to enter/generate this information. Geolocation Filed should be flexible enough to provide ONE database structure for any kind of input widget.
So first we need to define which information we want to store.
Comment | File | Size | Author |
---|
Comments
Comment #1
mcaden CreditAttribution: mcaden commentedI needed to display the address along with the map. All of the logic to deal with the addresses and everything was already there. I added it to the schema, then added options to the google maps widget. The address in this case is simply the "address" text field that is already in use. Here's the patch.
I agree with storing the full geocode data. I simply did this as a quick solution. Hopefully you can gain something from it.
Comment #2
supportPIC CreditAttribution: supportPIC commentedAnother way of doing based on a classical text field:
- add a text field in the content type.
- delete the text field in the module Goole map widget
- modify the js file to:
- impact the added text field for input => replace all off $(.geolocation-input) by $("#edit-field-geolocation").prev().find(':text').
- always update the formatted address from google in the text field => delete condition on mapclick line 21
I am new to Drupal so I even if it is working I don't know if it is a good way of doing... (and sorry I will learn to do patch files)
note: if you want to have more than one field using the module, you can too replace $(.geolocation-input) by $("[id^='edit-field-geo']") so that any field name field_geo... is impacted by the script.
Comment #3
derjochenmeyer CreditAttribution: derjochenmeyer commentedThanks for sharing this, supportPIC.
There are several possible routes that we could take in developing Geolocation Field.
#241484: Geolocation proximity filter for views.
All other data could be made available in tokens, and every user could choose WHAT he/she wants to store and WHERE (e.g. text fields). That's what supportPIC is suggesting and what we started to discuss here:
#1036056: Suggestion: Populate custom fields with geocoded data
That sounds the best option for me. We could start with the hCard (Wikipedia) microformat as a foundation. Here is another hCard specification. This sounds promising:
I want a solid, easy solution for the data storage and output. All fancy stuff can be accomplished by custom widgets and formaters.
Coming from there. If we want to be able to output this:
We need to store this (Barcelona Example from above):
Please feel free to tell me I'm wrong.
Comment #4
BenK CreditAttribution: BenK commentedSubscribing
Comment #5
BenK CreditAttribution: BenK commented@derjochenmeyer: Is there anything that precludes implementing option 2. first and then adding elements of option 1. as an additional feature?
For instance, in addition to storing the address as an hCard microformat, tokens could be provided for those who want to store the address some other way. I like a native and simple way to store the address that is provided by the module, but the flexibility to store it differently if needed.
We could then provide a checkbox setting that enables storage of the address by the module itself (as an hCard microformat). If this setting was left unchecked, then it would be up to the site administrator to use the tokens to store the data some other way. To facilitate this, we could provide a Rules module (http://drupal.org/project/rules) event when "An address was geocoded". Then using Rules' default "Set a data value" action (in combination with tokens provided by the module), site administrators could populate any custom fields on the site with the address information.
Thoughts?
--Ben
Comment #6
derjochenmeyer CreditAttribution: derjochenmeyer commentedHi Ben, thanks for sharing your thoughts.
This sounds like a good idea.
My focus is not on storing the information "as an hCard", but rather be able to output it as such. Token and Rules integration sounds very good. Have you experience as a developer with Rules and Token?
Comment #7
BenK CreditAttribution: BenK commented@derjochenmeyer: Sounds good. Yes, sorry for my sloppy language about storing "as an hCard"... I was just writing my comment quickly. I totally understand what you mean by output rather than storage.
As for Token and Rules integration, I've done a lot of testing/reviewing of contrib modules that integrate with those modules (as well as some limited development). However, I work regularly with a couple of developers who do a lot of development with Token and Rules. So if we were going down that path and needed some input, I could definitely ask them for some help.
Cheers,
Ben
Comment #8
derjochenmeyer CreditAttribution: derjochenmeyer commentedOk good, I'll typ to come up with a patch for a first implementation. But you are very welcome to jump in. As stated on the project page "Seeking co-maintainer(s)" :)
Comment #9
Alan D. CreditAttribution: Alan D. commentedWouldn't adding additional features like this take away from the share beauty of this module!! KISS
There are so many other geo lookup modules, like location, that are (IMHO) buggy and bloated.
An alternative approach is an independent module that supports multiple lookup engines & stores it's data in a custom multi-component field, which one of these could be a geolocation field.
Comment #10
mcaden CreditAttribution: mcaden commented@Alan: Isn't this thread simply talking about simply storage and display which are what a "field" does?
Storing the data in a detailed and structured manner drastically widens the possibilities of what can be done.
Comment #11
Alan D. CreditAttribution: Alan D. commentedfair enough.
here is a quick old school way (hacked so not to interact with existing module), like imagefield data array.
some wtf occurred, like serialize wasn't picked up & when using multiples, hook_field_is_empty() was not being called. possibly both major field bugs if there is not errors in my coding.
bad draw back - serialized data so bad / hard views integration
Comment #12
jjchinquist CreditAttribution: jjchinquist commentedWould not defining an API be the best route - define a hook_geolocation_field_store_address_info... and pass all address information from the google api in the hook? Then any contrib module could implement and manage the data. It would keep the geolocation field module separate and not truly responsible for the address data management.
Comment #13
Adam S CreditAttribution: Adam S commentedMuch of the function requests in this thread can be found using the OpenLayers Geocoder and OpenLayers Proximity modules. However, OpenLayers will not support any of these functions in Drupal 7.
Here I broke down the basic strategy of using a third party service (Google Maps API) to populate via Ajax text fields in a node form based on autocomplete by example of OpenLayers Geocoder. http://drupal.org/node/1044286#comment-4062056
If the Geolocation module can map Lat and Lon to a text field, the text fields then can be used to build an OpenLayers data map using Views. Super easy. To sum up extending this module is make it use information that is already available to populate text fields for other modules to use.
I would very much like to see an address widget that function exactly like the one on the add a business form of yelp.com.
Comment #14
steinmb CreditAttribution: steinmb commented#13 +1
Comment #15
ccardea CreditAttribution: ccardea commentedI just briefly took a look at this thread and I'm way too tired right now to take a serious look at anything, but I do have a couple of thoughts. First a little background, I've been working on a project in Drupal 6 using Openlayers Geocoder and Openlayers Proximity. There doesn't seem to be any interest on the part of the maintainers in porting those projects to Drupal 7, which is why I'm here. Now for my thoughts.
I probably have way too much to say for my level of expertise. I'm still trying to figure out how to do things in Drupal 6, but I think that may be about to change.
Comment #16
Adam S CreditAttribution: Adam S commentedThere is a discussion going on at http://groups.drupal.org/location-and-mapping. You should get involved.
Comment #17
lloydpearsoniv CreditAttribution: lloydpearsoniv commentedWhy not integrate it with a module that already stores addresses?
http://drupal.org/project/addressfield
Comment #18
steinmb CreditAttribution: steinmb commented@lloydpearsoniv that is one of the things we are discussing, if you follow the URL in #16. The group have created a wiki page where we try to sum it up, and a discussion thread Building the ultimate street address management system and geocoding module for Drupal 7. Pls join us over there :)
Comment #19
Mile23I'm just discovering this module, and I think I'll probably end up using it. :-)
Personally I think data could be stored minimally for v.1.0. That is, have table columns for lat, long, and the precalc'ed fields. Also have a column for 'data' that will be a serialized keyed array of whatever else comes back from Google. As the project develops, various use cases will show which information needs to graduate out of the 'data' pile and into its own column. This way, there is an achievable goal for v.1.0 and clear room for change.
My first suggestion: A date/time field so you can locate yourself in spacetime.
Comment #20
lloydpearsoniv CreditAttribution: lloydpearsoniv commented@steinmb
I followed the link & joined the convo right after i left my comment. Thanks for inviting me. ;)
Comment #21
ccardea CreditAttribution: ccardea commentedHey guys, sorry to have jumped in without giving the issue a thorough read first. I've seen some good ideas here and I have to admit I'm still a little fuzzy about how things work in Drupal 7. It seems to me that the basic idea of a field type module is to just to provide the field type definitions. It looks like you need to provide a default widget and a formatter but basically the field type definition is de-coupled from both the widget definition and the field storage definition.
Am I correct in assuming that you're trying to figure out the schema for your field, and just use sql field storage? If that is the case then it would be possible to define different field types with different schemas, and people could choose the one that works best for their use case. That might actually be the way to achieve the flexibility you're looking for, rather than trying to provide a single structure that works for every kind of input widget.
If you're writing a field storage module then that's a different problem. I should probably take a look at the code. I like the idea of providing tokens that can be used to complete other fields, but as I learn more about this, I'm beginning to think that is more the job of the geo-coder module.
Comment #22
Adam S CreditAttribution: Adam S commentedI've tried to make a hybrid between this and the Address field module. It can be found on github at https://github.com/adam-s/addressfield/tree/Plain . You can type in the address parts then click the geocode button OR just move the marker on the map.
Since on the website I'm building everybody will know their address there isn't much need to have the reverse geocode. I just though maybe somebody else would like it so I kept it there.
Comment #23
jjchinquist CreditAttribution: jjchinquist commentedI heartily agree with Mile23's suggestion.
Furthermore, I suggest adding a hook invokation after the data is prepared by Geolocation Field but before serialization and insertion into the DB. It would will allow other maintainers to manage the data in a customized fashion. I envision the scenario where the data should be saved twice, once with the serialized data before the invokation, and once with the data returned by all hook invokations. It could prevent legacy issues for future versions of the Geolocation Field.
Comment #24
ccardea CreditAttribution: ccardea commented@derjochenmeyer
I finally got around to checking out your module and I have to say this is nice work and I apologize being such an idiot. Focusing a little on your original thought:
AddressField is already doing that, at least the storage part, so I think it would be a mistake to duplicate what they're doing. (I've been doing a little code review and finding out that module duplication is being highly frowned upon by the powers that be.) Integration either by tokens or through an API would be way cool though.
Comment #25
jherencia CreditAttribution: jherencia commentedSub
Comment #26
larowlansubs
Comment #27
jm.federico CreditAttribution: jm.federico commentedI'm here just to say that I think using Address Field should be the way to go. It will be highly used because of commerce and seems good enough.
@derjochenmeyer
Any thoughts on going that way?
Comment #28
jherencia CreditAttribution: jherencia commentedWell, I don't know the current state of Addrees Field, but I think it just stores addresses. Most of the developers (me included) prefer Geofield because has integration with Openlayers ant its Views integration.
There are too many modules made to store locations in too many different ways, we should try to centralize efforts in just one and try to make it work in the most number of situations as possible.
Geolocation Field has a great input widget, so we should try to improve what it does better than any other module and let other modules to handle storage. Adding compability to geofield (#1129512: Make Google maps geolocation widget compatible with Geofield) is a necessary step in that direction.
Comment #29
steinmb CreditAttribution: steinmb commented@jherencia pls read #18
Comment #30
Summit CreditAttribution: Summit commentedSubscribing, greetings, Martijn
Comment #31
brandy.brown CreditAttribution: brandy.brown commentedI implemented the patch in #1, but I get this error: Notice: Undefined property: stdClass::$field_location_address in field_sql_storage_field_storage_load() (line 336 of /modules/field/modules/field_sql_storage/field_sql_storage.module). Ideas?
Comment #32
mototribe CreditAttribution: mototribe commentedSub
Comment #33
andrea.cavattoni CreditAttribution: andrea.cavattoni commentedsubscribe
Comment #34
vhwouter CreditAttribution: vhwouter commented@brandy brown: same here.
sub
Comment #35
phayes CreditAttribution: phayes commentedHi guys, just an FYI that geocoder module (http://drupal.org/project/geocoder) is now stable and has an AJAX API. It might be a good idea to use it as your geocoding backend. For addresses it currently supports google, yahoo, and yandex (russian) with more on the way.
Also note that it already has support for geolocation in a non-interactive fashion. (grab an address or text field and geocode it to a geolocation field on entity save)
Comment #36
Sinan Erdem CreditAttribution: Sinan Erdem commentedAre there any improvements on this issue?
I really like to store address data (preferably city and country in separate places), but couldnt find a solution yet.
Comment #37
phayes CreditAttribution: phayes commentedetcetera9,
You can now do this with addressfield, geocoder, and geofield modules.
Comment #38
Sinan Erdem CreditAttribution: Sinan Erdem commented@phayes,
Without using Geolocation module?
I am not sure if Geocoder does reverse geocoding yet. What I want is that user selects a point from a map, then I store the address info (city, country etc) in another field.
If you know the way to do it, can you please briefly explain it?
Comment #39
derjochenmeyer CreditAttribution: derjochenmeyer commentedThanks for the input and all the thoughts on this topic.
If anybody is interested in further discussing the details, I will split this in to seperate issues for each feature. Starting with
#1780092: Introduce new 'data'-column to store whatever comes back from Google's Geocoder
Thanks Mile23 for comment #19.
Comment #40
Anonymous (not verified) CreditAttribution: Anonymous commentedI would like to do the same thing like this: Use another Geolocation field for "Set location" button
But a bit different:
My idea, i make my own CCK adressfields (in the top of the screenshot below) and the user fill in the adressdata in this fields. The adressfield from the geolocation-module is hidden. The data from the CCK fields will automatically copy to the hidden geolocation-adressfield. After filling, the user click on the visible button "Get location". After that, i have all data that i need. The longitude and latitude compatible to the adressdata from the CCK-fields. But i have no acces to the geolocation-adressfield... Where is the data stored from this field? I know... not in the database... But when i edit a user i can see the data in the field, thus, the data are stored somewhere or I'm wrong? Can anybody help me with this?
Comment #41
derjochenmeyer CreditAttribution: derjochenmeyer commented@FeanorCC its not stored. Only lat,lng is stored. The adress data you see, is the closest address returned by googles geocoder (reverse geocoded from lat,lng).
Comment #42
TravisJohnston CreditAttribution: TravisJohnston commentedThe patch included at the top has the right idea, but is not compatible with the recent version of Geolocation. Anyone willing to rewrite it? The ability to show the address instead of "Geolocation Long 999999999 Lat 99999" is a pretty common need and should be a default option to show the Address and the Address + Map. Integration with Location Module could help.
Comment #43
TravisJohnston CreditAttribution: TravisJohnston commentedI managed to get this working. In my case, there turned out to be a select number of locations that were going to be used often in the website so I did this.
Create a Location Entity (Content Type)
- Postal Address Field for standard address information
- Geolocation Field for map
Create an Entity Reference field in the chosen entity, for my case it was a Commerce Product Type
Then your done. Obviously only works with with a specific set of locations, though the benefit of this is its able to be searchable and both the address and the map show.
Comment #44
pcbudde CreditAttribution: pcbudde commentedHas this patch been made compatible with the latest version of geolocation?
Travis I do not understand your example. Do users then have the address field module to input data?
I could really use this functionality however I am not a seasoned php user. Can the previewed address that is shown with geolocation be stored with a computed field and how?
Comment #45
derjochenmeyer CreditAttribution: derjochenmeyer commentedThis issue needs a direction :)
First of all we discuss two things here:
The first task is easy to accomplish but at the same time not very useful.
The second task (store data that Google geocoder returns) may violate the Google Maps API Terms of Service.
See this link.
Well what is a "limited period"?
However even storing latlng values for an "unlimited period" or displaying the data outside of Goolge Maps or Google earth violates the Google Maps API Terms of Service.
But on the other hand this very much depends on the type of service a website offers. Using the geocoder to get address and geolocation data is certainly what Google wants and encourages us to do. Well and creating a node is kind of caching that data (certainly as long as we display a Google map alongside the data).
So back to the beginning. What should we store?
Google returns a lot of stuff.
The easiest option is to store the formatted_address which is just one string seperated by commas.
But there will be users who want more controll. Storing all possibly returned stuff is certainly too much. Storing just the string might be not enough.
Comment #46
pcbudde CreditAttribution: pcbudde commentedokay I see. Its difficult to select which data is the most important because each website has its unique demand.
Would it be possible to create user settings where its possible to change the lookup to the desired address?
Currently I am only in need of the country to make it sortable in views global filter. (what would a quick workaround be?)
Comment #47
JordiTR CreditAttribution: JordiTR commentedJust my 5 cents. Why no saving on a new column what the user entered on the address field? On the module description it clearly states to focus on being a light-weight, easy-to-use solution, in front of more complex proposals. That's what I think it makes great this module. So... where's the problem to store the address entered by the user to be rendered by a formatter as an alternative option?
There´s no need to develop highly flexible address models, since then maybe the module also should develop more complex mapping solutions, shouldn't it? If that solutions for storing and presenting addresses was not enought for some people, no problem, there are other modules for Drupal mapping and addressing. Maybe the mapping solution offered by this module is not enough for many people that finally decided to use other modules (and there are tons of users who took that direction).
What I can't understand is why I'm not able to display on the page the simple address I entered next to the map, being a "light-weight" solution ;-)
Comment #48
kvit CreditAttribution: kvit commentedSupporting #47
Comment #49
derjochenmeyer CreditAttribution: derjochenmeyer commentedI really want to find a clean solution for storing user input and addtional "meta" information provided by the gecoding service.
But the hurdle we have is that Geolocation field stores input from different widgets. Even on the same site different widgets could be used, e.g. Google Maps for Desktop users and HTML5 Geolocation for mobile users. Or HTML5 for comments (like facebooks "share my location" option) while when adding an event a text based input would be required.
If then we want to display locations entered with different tools, we have to deal with a differing data structure.
In HTML5 geolocation the browser always returns lat, lng and accuracy while some information is optional (timestamp, altitude , altitudeAccuracy, ...). Accuracy is important information, and maybe later we want to display only locations with a accuracy higher than X. While other widgets won't provide this piece of information at all.
Comment #50
JordiTR CreditAttribution: JordiTR commentedHi Jochen and thanks for your nice module!
I understand your worries for having a solid data model, a good architecture. But I think people is asking for something different, simply having the choice to print the address on screen... keeping the " light-weight, easy-to-use solution" philosophy. So, maybe is interesting to have a data container, somewhere on the database, for saving the different models you preview. But on the other hand I feel people is asking for a new column on the database where the address entered is saved and a formatter for rendering it next to the map. IMHO :-)
Comment #51
derjochenmeyer CreditAttribution: derjochenmeyer commentedThanks for the feedback. It still reminds me of Pandora's box :-)
Everybody has a slightly different usecase
All are 100% valid usecases.
Sure, not storing and not beeing able to use any of that information is bad. Geolocation Field needs that feature. I totally agree, I just dont see any generic solution.
Maybe this one. Geolocation provides 2 hidden fields without beeing responsible for storing this information. One for user input one for user output.
This data can then be used in hooks, tokens, etc. and for every usecase the information can be handled differently, and passed to a seperate textfield, address field, etc.
Another option is to store selected data:
But then geolocation field (and the stored data) depends on the widgets and formatters.
Pandora's box.
Comment #52
JordiTR CreditAttribution: JordiTR commentedHi Jochen. As long as I've participated on that thread I just would say that openning the Pandora's box would be trying to push the module too far from its initial goals, which were the goals you decided initially. I think on the model "lightweight solution" that you promote on the description of the field. So, we input an address, the systems prints that address, or the map, or thee coordinates. That simple :-)
Openning the Pandora box probably would move me to another more complete solutions for addressing or mapping, and I've already done it on complex projects. That's what I love of your project, the simplicity... but I still lack the possibility to print the address I used to get the map :-)
Comment #53
JordiTR CreditAttribution: JordiTR commentedThe only debate, for me, is: saving the user's initial address or the one returned by Google...
;-)
Comment #54
heddnre #45: Google's TOS state 30 days: https://developers.google.com/maps/terms#section_10_1_3
Comment #55
derjochenmeyer CreditAttribution: derjochenmeyer commentedThat means it already violates Googles TOS to store lat, lng values and to begin with, even create a "Wrapper" like the Geocoder widget of this module?
Bad news: https://developers.google.com/maps/terms#section_10_2
Or is there another interpretation?
Comment #56
heddnGoogle isn't the only one out there in the pond. Bing lets you store lat/long. And even Google encourages caching of lat/long, just not longer than 30 days. So for Goole just set up a cron run to flush the data prior to 30 days and everything is fine.
Comment #57
derjochenmeyer CreditAttribution: derjochenmeyer commentedWhat about storing a GeoJSON string.
In addition to the indexed and queriable lat, lng values this could make sense to store any additional information.
Anybody who can give advice on how to store GeoJSON?
Comment #58
mtoscano CreditAttribution: mtoscano commentedThe lack of this feature is blocking me from using this great module, that offer much better user experience in the edit form. We definitely need a way to display the address, and if Google TOS are too restrictive probably we need to look somewhere else.
Anyway, at least the option to store and display the address entered by the user can be a good staring point.
Comment #59
mtoscano CreditAttribution: mtoscano commentedI tried to use the solution provided here https://www.drupal.org/node/1369390#comment-6854534, adding the code to the geolocation.js in the geolocation folder, modifying the field name to match mine and clearing the cache, but it doesn't works.
Should I put that jQuery code in geolocation.js or somewhere else?
Comment #60
dinarcon CreditAttribution: dinarcon at Agaric commentedHello,
I needed to store the formatted address along with the other field information. This is suggested in #45, although it seems that storing any information permanently is against the TOS as referred in #54. Does flushing the data and bulk importing it again would overcome this limitation?
While we figure this out, let me share a proposed implementation for this feature. The recipe that I followed is:
The attached patch applies to the latest dev and stable versions.
What are your thoughts?
Comment #61
dinarcon CreditAttribution: dinarcon at Agaric commentedComment #62
mikefyfer CreditAttribution: mikefyfer commentedAny hope of this getting added to the D8 branch?
Comment #63
derjochenmeyer CreditAttribution: derjochenmeyer at forward-media.de commentedThis is my personal top feature request. I would love to have a patch for D8 address module integration.
Comment #64
Summit CreditAttribution: Summit commentedHi,
I would love this in D7 and then ported to D8:) A lot of people, like myself are still on D7 because also of other modules which are not developed, or not enough developed on D8.
Thanks for your hard work on this great module until now!
Greetings, Martijn
Comment #65
giufog CreditAttribution: giufog commented#60patch per me non ha funzionato (errore del server)
Comment #66
platinum1 CreditAttribution: platinum1 commented@derjochenmayer I would love the integration you proposed in #63
Comment #67
malcomio CreditAttribution: malcomio commentedYes, integration with Address would be great - I've created #2681335: Dump address result from geocoder widget in address field on the D8 version for this.
Comment #68
hanoiiNice patch!!! Well, it works. Obviously as stated by @dinarcon, you MUST apply #691932-92: Add hook_field_schema_alter().
I just improved very lightly by pre-filling the previously stored address in the address field and preventing the reverse geocoding to work on load. This is because you expect an entered address, even after reverse geocoding, to be kept as is, rather than somehow translated to a range of addresses.
Comment #70
hanoiiSomething was not quite right in the previous patch, as I missed something with latest dev. I don't think #60 works on dev, it needs to be re-rolled. This one applied fine to 1.6.
Comment #72
hanoiiHmm, another issue with the original patch. sorry.
Comment #73
Alan D. CreditAttribution: Alan D. commentedComment #75
hanoiiIt's failing tests because it doesn't apply properly to dev. I will review but something added by this patch on #60 doesn't seem to still be there on dev, so probably either removed, reworked or something. It does need a proper reroll for dev.
Comment #76
hanoiiSome code was moved to an internal function.
Attached is a patch that applies properly to dev so tests passes, although there aren't any, but so it shows as needs review.
Comment #78
hanoiiComment #79
hanoiiFixed an undefined notice.
I will work on the patch against dev only for now on. See interdiff for the simple fix for the stable applying patch in #60.
Comment #81
hanoiiAnother undefined notice
Comment #83
hanoiiTests are failing because of #2645590: Ensure that simpletest job doesn't "fail" testing if no tests are present
Comment #84
mtoscano CreditAttribution: mtoscano commentedApplied #83 and #691932-92: Add hook_field_schema_alter(), but at the end I wasn't able to test because the new field formatter called 'Reversed geocoded address formatter' does not support Geofield as storage, and even on form edit the user submitted address is not retained.
Anyway this solution requires core patching (at least in Drupal 7), not the best way to store address in this module.
Comment #85
panhead490 CreditAttribution: panhead490 commentedTried to use the hook_field_schema_alter() patch and it ran fine but is there anything else that I need to do? Not seeing the table structure change.
Thanks for any help or guidance. Forgive the file/patch references -- thought I had everything unchecked but alas I did not.
Comment #86
jeppy64 CreditAttribution: jeppy64 commentedLet me start by saying I am not a module writer, or even coder for that matter. But I have been following this thread for a while. This module is super as is but I do see a very valid need for the plain text address concept. The address field is great but it's hefty in many ways and almost "too much" complexity in my opinion. Maybe looking at the Simple Google Maps module would offer a new thought direction? If there's a way to combine what that module does with the single plain text field taking comma separated address values and bundling that into what this module has... it's a winner as I see it.
Comment #87
lias CreditAttribution: lias commentedI would like to second jeppy64 comment re: adding plain text address to this module. I also think Address in 8x is just too much - I have no need for commerce features and all the dependencies.
I've used Simple Google Maps paired with Computed Field to provide a basic map and text address display but would LOVE to be able to add additional addresses to map and proximity search.
That would be a great location/map module and it seems like Geolocation Field is almost there.
If there is a module out there that already fits this description and is production ready for D8 I'd appreciate a pointer - not Address please.
Comment #88
imclean CreditAttribution: imclean at Digital Ink commentedI've had a quick skim through but I'm not completely sure of the scope of this issue. From the issue summary, it appears caching the responses from the Geocoder would be a good first step.
We're using the Drupal 8 version with Nominatim which has a usage policy which includes:
We're using the API directly via
Drupal\geolocation\GeocoderManager
, so we could set up some custom caching. It will also have some pretty limited lookups, with possibly around 10 to 20 different places in total. Which, based on the usage policy, necessitates some local caching.This could be a simple key:value storage of the lookup. For example:
Key: "Town, State"
Value: serialised location result
Comment #89
imclean CreditAttribution: imclean at Digital Ink commentedAny caching should probably be more flexible. For example, the following, and other variations, should all return the same cached response:
Comment #90
ChristianAdamski CreditAttribution: ChristianAdamski as a volunteer commentedClosing all 7.x issues. It's time.