Ashish Ranjan Vor 9 Jahren Nice Feature !!! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Daniele Baggio Vor 9 Jahren We implement this feature manually in far old Liferay 6.06 version. It's OK to have now a built-in feature! Go on! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Jader Francia Vor 9 Jahren Great work Juan!We LOVE the geo functionality you are working on; thanks again for the effort! ;)Cheers, J. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Fabio Sventer Vor 9 Jahren We are pleased to this blog, because we have developed a geolocation solution for Liferay 6.1 and 6.2 to display and search all default assets and custom assets, across a Google Map, OenStreet Map or Bing. This solution called MapIt and it's present on MarketPlace and won at the last Liferay Contest. So for us is an amazing news have a built in solution to do all this feature. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Ludovic Andrieux Vor 9 Jahren Sorry but the best part for me is :"we are currently implementing DDMStructure based custom fields"It's an incredible powerfull solution ! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Andrea Di Giorgi Vor 9 Jahren I like it, keep up the good work! :-) And what about extending the geolocation support to any type of asset? For example, with a dedicated table and a taglib? So even assets that don't use the DDM framework can be geolocalized. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Jader Francia Andrea Di Giorgi Vor 9 Jahren It's a good idea!It would be very practical to geolocate custom assets using a bus inside the platform!+1 for me! ;) Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Jader Francia Andrea Di Giorgi Vor 9 Jahren It's a good idea!It would be very practical to geolocate custom assets using a bus inside the platform!+1 for me! ;) Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Mauro Mariuzzo Vor 9 Jahren IHMO, adding geo-localization only as DDM filed is only a good start.I agree with Andrea, this has to be added as a taglib to allow people to use it on custom asset or inside standard assets (MessageBoard, Blogs, Wiki).Like rating system, geoloc needs to have his own database table, that allow developer:* to do sql having that table in the from clause (power)* to have geoloc in a standard field inside Indexer* have multiple coordinates linked to a single elementActually (6.2) an Asset Publisher allow you to filter or order for DDM fields only if you configure it with a specific asset subtype. This is a big limitation if I want, for example, implement an AssetPublisher showing WebContent and Documents related to a specific GeoLocation.With a standalone entity this use-case can be more easy to solved.Having a standalone table you can use database specific geospatial functionality to solve problems like:* things 30km far from this point* things inside NorthWest-South-East rectangleOn the UI side, you have to allow user to choose a position different of the one detected by gps.For standard browsers would be good to have a popup with a map and a search field.As Maps system both Google Maps and OpenStreetmap have to be implemented. Better if maps engine is plugable. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Juan Fernández Vor 9 Jahren Wow! So many comments! Cool! Here are some answers to your questions:- Some of you ask for supporting geolocation on assets. We are planning something better: we are going to add this as Expando field type when we move Expando to DDM, so every entity (and not only assets) will benefit from this. - We have created JS modules that allow to create maps and listen to events to get data and show the info. We support both GMaps and OpenStreetMaps - The new taglib liferay-ui:maps make use of these modules to geolocalize or show geolocalized modules. - The UI team is working to make these components OSGi modules, so that you can deploy and use any kind of map implementation and also mae them available as marketplace apps. - We'll write another more technical blog entry when we have the OSGi modules ready for you. Thanks for your feedback! Keep it coming! ;)Juan Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Paco Alías Juan Fernández Vor 9 Jahren waiting impatiently! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Paco Alías Juan Fernández Vor 9 Jahren waiting impatiently! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Thomas Detoux Vor 9 Jahren Awesome, this new feature will rock ! I especially love the map asset publisher.Since you asked for thoughts and ideas, here's what poped in my mind :- A new search facet (results within 500m, 5km, 50km of user location) is definitely something we can use,- Add some geoname lookup, so that users can type a street address instead of finding a place on a map (in the case someone will want to add content located somewhere they are not) Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Juan Fernández Thomas Detoux Vor 9 Jahren Hi Thomas! Thanks for the feedback The search facet is something we are currently analyzing and good news are that geoname lookup is already done! ;)I'll update you about our progressBest!Juan Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Juan Fernández Thomas Detoux Vor 9 Jahren Hi Thomas! Thanks for the feedback The search facet is something we are currently analyzing and good news are that geoname lookup is already done! ;)I'll update you about our progressBest!Juan Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Mauro Mariuzzo Vor 9 Jahren I'm not so excited about DDM. Actually the storage can be an XML string inside a table field, or Expando Tables (until it will be merged inside DDM).Let me identify a use case: I want to have the list of Blogs Entry, Wikis, And CalendarBookings geolocated inside a rectangle identified by NW="45.566265, 12.151319" and SE="45.403069, 12.445890".AssetPublisher ootb uses search engine to retrieve the assets I'm able to see. To build a valid query I need to have the geo-coordinates inside the index. And for every coordinate I have to do a specific filter "longitude between W and E", "latitude between "N and S".Using Expando I can have the Blogs one called "Place", the Wiki one called "Where" and Calendar one called "Location".I know, is a strange worst case, but this can happen. I we have to provide a good interface to allow user to configure AssetPubblisher to gain his goal.And if want, or need, to use database to collect the same assets?It is not simple to make a query where the condition is based on elements inside a string field. Maybe some db-engine are able to do that more powerfull that others. But the performance are not exciting.DDM are powerfull but doesn't covers all needs. Sometimes users prefer to create a portlet with custom assets to have full control of data via indexer and via SQL.To solve questions like "5Km from this point" actually I'm using database geoquery extensions. Having coordinates stored as known fields helps alot Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Jorge Ferrer Mauro Mariuzzo Vor 9 Jahren Thanks Mauro, those are definitely good points.A counter argument could be that in some cases you need two fields with coordinates. Maybe one solution that would address all needs would be to have an standardized custom field for the location that has a predefined name. It will still be possible to add additional fields of type "Location" with custom names if needed. What do you think? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Mauro Mariuzzo Jorge Ferrer Vor 9 Jahren Hi Jorge,actually I'm not able to argument, in terms of performance or custom needs, if your solution to have geo location inside DDM infrastructure is good or worst about having it in a specific database table.We have implemented a geo solution on Liferay 6.0 and we decided to have a separate table (with two separated field for latitude and longitude) to be able to filter assets by coordinates (in 6.0 Asset Publisher uses D. And sort it.And have a taglib to allow use to add coordinates to standard assets but also to custom ones.In the Marketplace there are some plugins developed by 3F Consulting. They use custom fields (two separated field for latitude and longitude) to add coordinates to the assets and are able to filter it. Some filters are done on client side other server-side using Indexer (because fields has standard name) or DB (because Expando values are stored on D.I hope the final liferay solution will allow developers two goals:* easily adds coordinates (at least one pair) on custom assets * easily grap assets related also to a "geo-rectangle"Having a framework providing it we can provide information for "augmented reality solutions", "internet of things solutions", "mobile / desktop / portlat apps", everything Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Jorge Ferrer Mauro Mariuzzo Vor 9 Jahren Thanks Mauro, those are definitely good points.A counter argument could be that in some cases you need two fields with coordinates. Maybe one solution that would address all needs would be to have an standardized custom field for the location that has a predefined name. It will still be possible to add additional fields of type "Location" with custom names if needed. What do you think? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen Mauro Mariuzzo Jorge Ferrer Vor 9 Jahren Hi Jorge,actually I'm not able to argument, in terms of performance or custom needs, if your solution to have geo location inside DDM infrastructure is good or worst about having it in a specific database table.We have implemented a geo solution on Liferay 6.0 and we decided to have a separate table (with two separated field for latitude and longitude) to be able to filter assets by coordinates (in 6.0 Asset Publisher uses D. And sort it.And have a taglib to allow use to add coordinates to standard assets but also to custom ones.In the Marketplace there are some plugins developed by 3F Consulting. They use custom fields (two separated field for latitude and longitude) to add coordinates to the assets and are able to filter it. Some filters are done on client side other server-side using Indexer (because fields has standard name) or DB (because Expando values are stored on D.I hope the final liferay solution will allow developers two goals:* easily adds coordinates (at least one pair) on custom assets * easily grap assets related also to a "geo-rectangle"Having a framework providing it we can provide information for "augmented reality solutions", "internet of things solutions", "mobile / desktop / portlat apps", everything Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Mauro Mariuzzo Jorge Ferrer Vor 9 Jahren Hi Jorge,actually I'm not able to argument, in terms of performance or custom needs, if your solution to have geo location inside DDM infrastructure is good or worst about having it in a specific database table.We have implemented a geo solution on Liferay 6.0 and we decided to have a separate table (with two separated field for latitude and longitude) to be able to filter assets by coordinates (in 6.0 Asset Publisher uses D. And sort it.And have a taglib to allow use to add coordinates to standard assets but also to custom ones.In the Marketplace there are some plugins developed by 3F Consulting. They use custom fields (two separated field for latitude and longitude) to add coordinates to the assets and are able to filter it. Some filters are done on client side other server-side using Indexer (because fields has standard name) or DB (because Expando values are stored on D.I hope the final liferay solution will allow developers two goals:* easily adds coordinates (at least one pair) on custom assets * easily grap assets related also to a "geo-rectangle"Having a framework providing it we can provide information for "augmented reality solutions", "internet of things solutions", "mobile / desktop / portlat apps", everything Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Pankaj Kathiriya Vor 9 Jahren Really nice feature! ++1. Keep it up! Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Nilang I Patel Vor 9 Jahren G8 feature. Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen
Maxym Maxym Vor 5 Jahren Is it possible to modify that geo api that way user can add route when adding new article, without creating custom portlet? Just the same way as adding that geo? Melden Sie sich an, um auf diesen Beitrag zu antworten. Antworten als... Abbrechen