wiki:Places
Last modified 4 months ago

Draft for the new Places | Groups-locale application

Goal: To provide a system that offers group functionalities to geographic places where we have members (cities, regions, countries). Intuitive browsing based on the hierarchy of geographic places should be offered.

List of all countries sorted by continents

Continent Page
-- dropdown list of all cities in this continent
-- list of 15 major cities (by nb of members) in this continent
-- list of all child countries (paginated)

Country Page
-- dropdown list of all child regions in this country
-- list of 15 major cities (by nb of members) in this country
-- list of all child regions (paginated)
<< backlink to continent

Region Page
-- dropdown list of all child regions in this region
-- list of 15 major cities (by nb of members) in this region
<< backlink to country
<< backlink to continent

Region Page
-- dropdown list of all cities in this region
-- list of 15 major cities (by nb of members) in this region << backlink to parent region
<< backlink to country
<< backlink to continent

City Page
-- link to nearby cities
<< backlink to parent region
<< backlink to parent region
<< backlink to country
<< backlink to continent

Source of geographic / hierarchy information

We get the geographical info from GeoNames:  http://www.geonames.org/

Feature codes used by GeoNames:  http://www.geonames.org/export/codes.html

entities used to retrieve information

In the framework, there are some data entities that can be used for easy data retrieval.

  • Geo: main geo entity, coupled with the geonames_cache table. Notable functions:
    • getParent()
    • getAncestorline()
    • getCountry()
    • getChildren()
    • getHierarchyChildren()
    • getHierarchyParents()
    • getAlternateName()
    • getName()
    • isChildOf
  • GeoAlternateName: coupled with geonames_alternate_names. Notable functions:
    • getNameForLocation()
  • GeoHierarchy: coupled with geo_hierarchy, provides access to the location hierarchy. Notable functions:
    • getAllParents()
    • getAllChildren()

There are other geo entities, look in /build/geo/ for more information. Most of them are coupled with Geo - so in general, use Geo to get what you need.

tools / group features available

design drafts

 http://www.bewelcome.org/gallery/show/image/2457

TODO

  • Continent-Support

We don't plan with a support for parentIds for the countries yet (continents). As places show continents too, it would be nice to be able to point to them (even if only as a link to /places). What's the way to go? Go on using the geonames_countries table? Then we should integrate that in the geo-entities.

If I'm not mistaken, continents are represented in geonames_cache - and in geo_hierarchy (according to Philipp). So, the Geo entity should have some methods added, like getCountry and getContinent that return the country and continent of the location, respectively. Both should take their data from geo_hierarchies, not geo_countries. Peter

  • Advanced routing

Currently it's not possible to surf pages like "/places/DE/Land Berlin/forum" or "/places/FR/members". How do we make this possible?

'/places/forum/location' will work now, same for '/places/members/location' and '/places/wiki/location'. Peter

  • Extending Page Classes

Will we GeoGroupForumPage extend GroupForumPage or GeoGroupStartPage? We need stuff from both pages for GeoGroupForumPage...

Consider an abstract base class for the geo pages, if all of them share functionality. Peter

How and when will members join a GeoGroup/Place?? Under which circumstances will members be able to leave a group?

For now I propose the following routines: Micha

  • Upon signup: member joins all geo groups in the hierarchy of the choosen location
  • Upon manual location change (/setlocation): joins geo groups in hierarchy of the new location
  • Upon manual request to join a geogroup (/places/join/location): member joins the requested geo group
  • Upon manual setting (/groups/mygroups): member leaves any choosen group, except for the ones in the hierarchy of his current location

Testing

Current core functionality of the geogroups can be tested here:  http://muks.org/dev/rox-geo/htdocs/places/

For the geogroups admin functions:  http://muks.org/dev/rox-geo/htdocs/admin/groups

I'll try to update the installation as often as possible - Micha

Discussion

Can you give an example why users should request to join a geogroup/place? Matthias

Sure: Let's say a member living in New York, USA, wants to visit some places in Europe next summer. He might want to join some local groups like "Europe", "Berlin", "Paris", "France" etc. to know about things going on a local level before his actual visit. While I would still let everyone (also non-members) post messages in local groups, you'll only get notifications about group activity once you sign up (which makes sense!). We would come closer to the way CS handles groups, I guess. Does that convince you? Micha

Ok. That would mean we would have two kinds of group members?

  • 1. Residents, the people who live in that place and
  • 2. Visitors, mostly temporary members of a group, who are only interested what's going on in a certain place.

If we can visually separate those two, i am totally fine with it. Matthias

Now that I think about it, maybe it's too complicated that way. Also it makes it hard to introduce the new local groups without yet more major changes. I change my current proposal: Users should only belong to one hierarchy of geo locations (Europe > Germany > Berlin > Berlin) and shouldn't be able to change it until they change their current address/location. Users should additionally have the option to "watch" any group (local and other) that's public without joining it. This feature can be introduced seperately later. Micha

My proposal would be to leave and join the geogroups as easy as a normal group. Only difference would be that you will be automatic added to your address location. And if you move Berlin->Paris you stay in the Berlin geogroup (you can leave manually) and you will be automatic added to Paris (you can leave manually) No functional differences for "watchers", "Visitors" or "Residents" , please. Manuel

Although, I sympathize with this proposal, I think it would lead to certain problems. "Places" is and will be the place to search for hosts on your travel.

  • If we would list members in a geogroup that don't actually live at the corresponding location but rather have an interest for it, then people looking for hosts will be more than confused.
  • If a member can always leave a geogroup (even if he still lives in that place), people looking for a host couldn't find him anymore. However, to avoid that, we could list not the members in the group but actually the ones that have the location set as their address. Then again: Why do we integrate groups and places at all, if not to integrate their functionality?
  • Note, that as a group member you always have the option to receive messages from the group or not. So, why should we give our users the possibility to leave their local geogroup at all? What could be a good reason for them to want that? Micha