There is no place in PhpGedView to place generic media files that are relevant to places. They need to be put with events or people and that is ugly and redundant.
Traditionally, GEDCOM does not allow this because places were little more than strings. However, many genealogy programs, PhpGedView included, have tried to organize those place strings in one way or another. Place hierarchy is but one example, but googlemap has only made this clearer and the creation of the placelocation table was needed to hold shared information for the place.
GEDCOM itself shows signs of moving (if "moving" is applicable at all to GEDCOM, of course) in the direction of adding subbordinate information to places as exhibited by the addition of MAP in 5.5.1.
Design details are tricky. In fact, places are begging to become first-class objects, but going all the way that route might be too much. But it mirrors the evolution path of SOUR and OBJE, IIRC, along the GEDCOM life. Two syntaxes would be needed for PLAC records. The first one would be the current syntax for compatibility with current programs. The new one would use a pointer like this:
0 INDI
...
1 BIRT
2 PLAC @P7@
....
0 @P7@ PLAC
1 TITL <place name>
1 MAP
2 LATI ...
2 LONG ...
1 OBJE ...
or something in that line. Other programs, like GRAMPS, could follow this route (it currently does not really know what to do with place-media on GEDCOM export nor place-notes, etc.).
Logged In: YES
user_id=808700
Originator: NO
this is also linked with 1777719
Logged In: YES
user_id=634811
Originator: NO
some of this should be added to the wiki for proposed GEDCOM 5.6 changes
Logged In: YES
user_id=45958
Originator: YES
Where is the proposed 5.6 changes wiki? The recent report about the nonstandard _PLAC tag in RootsMagic has rung a bell. It seems they perceived the same need.