[talk-ph] Various
Eugene Alvin Villar
seav80 at gmail.com
Tue Nov 25 14:31:27 GMT 2008
I checked the "legal" definition of a "city" in the UK and it is not based
on population size. So I'm convinced that "place=city" meaning a settlement
with 100,000+ residents is not a UK-centric thing.
However, I don't think this matches how Philippine cities and municipalities
are tagged in OSM. If it's a legal city, it gets "place=city" and
"place=town" if a municipality. Legally, a city needs to have a population
of at least 150,000 (based on the 1991 Local Government Code) so I'm
confident that all cities in the Philippines correctly get the "place=city"
tag. However, there are many municipalities that have more than 100,000
residents. For example, Dasmarinas, Cavite has a population of 500,000+.
Here's a possible solution: can the place tag get more than 1 value
separated by commas? So maybe we can tag Dasmarinas with
"place=city,ph-municipality". We could have Philippine-specific values:
"ph-city", "ph-municipality", and "ph-barangay" and retain "city", "town",
and "village" for international compatibility.
On Tue, Nov 25, 2008 at 4:15 PM, <soeren.rabenstein at email.de> wrote:
> Hi Guys,
>
> Ok I also checked the discussion over there @nabble.com.
> There is a valid point in the concern that the map becomes unmanagable as a
> world map if things become tooo localized.
> I mean in fact, if now the Swedes tag their roads as "väg=x" (saying that
> the Swedish road claissificationn system was totally different from the GB
> one), then tomorrow the Germans come and say "we dont have motorways here,
> we only have Autobahn" .... and so on and so on. At the end of the day you
> need a dedicated renderer for each country and language. (And hell, we have
> 193 countries and thousands of languages on this planet.)
> On the other hand it is also a valid point not to loose localized
> information due to a "too British" classification of everything.
>
> So my solution - in fact for the global issue in the big picture - would be
> to introduce something like a "nat_place=x" or "loc_place=x" tag, which may
> be used for a local definition IN ADDITION to the global "place=x" tag,
> which remains in the (rather British) numerus clausus we have.
>
> What do you think?
>
> Cheers
> Soren
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: "Ian Haylock" <haylocki at yahoo.co.uk>
> > Gesendet: 25.11.08 00:43:35
> > An: Eugene Alvin Villar <seav80 at gmail.com>
> > CC: talk-ph at openstreetmap.org
> > Betreff: Re: [talk-ph] Various
>
> >
> >
> > Hi,
> >
> > But barangays are not exactly villages, which is unlike Philippine
> > municipalities that are acknowledged equivalent to towns.
> >
> >
> > The Place= tag is used to denote the population size of a place, not
> > whether a place is actually a city, town, village etc.
> >
> >
> > So someone listing all the world's "villages" would get inaccurate
> > data. Besides, I personally find very little use for a list of all
> > the world's villages for whatever analysis that list would be needed
> > for, unlike say, a list of all cities.
> >
> > That was a "Hypothetical" example.
> >
> > A non Hypothetical example (though not country specific) would be the
> > change from highway=gate to barrier=gate. Previously navigation S/W
> > only had to search for highway=gate to find roads to ignore. Now it
> > has to search for both, twice as much work for the same result.
> >
> > (Hmmm, maybe the "place=x" tags should also be accompanied with the "
> > admin_level=n" tags especially if the place matches the admin_level?
> > Seems like a good idea, don't you think?)
> >
> > Now that gets a +1 from me :-)
> >
> >
> > On Mon, Nov 24, 2008 at 10:04 PM, Ian Haylock <haylocki at yahoo.co.uk>
> > wrote:
> >
> >
> > Sorry,
> >
> > -1 from me.
> >
> > I think using country specific tags like "barangay" will cause
> > problems with people who use the data.
> >
> > As a hypothetical example, suppose someone wanted to list all the
> > villages in the osm database. If all the different countries used a
> > different name for village, such a simple task would become a pain in
> > the A**.
> >
> > Cheers, Ian
> >
> > --- On *Mon, 24/11/08, *maning * sambale *<emmanuel.sambale at gmail.
> > com> wrote:
> > From: maning sambale <emmanuel.sambale at gmail.com>
> > Subject: Re: [talk-ph] Various
> > To: "Eugene Alvin Villar" <seav80 at gmail.com>
> > Cc: talk-ph at openstreetmap.org
> > Date: Monday, 24 November, 2008, 8:58 AM
> >
> >
> >
> > +1 for me. That would be fairly easy for me to
> > change the
> > place=village to place=barangay. But only for the ones I added. If
> > others would allow me to do so for them, I'll do it.
> >
> > What about the others? Any opinion on this?
> >
> > cheers,
> > maning
> >
> >
> > On 11/24/08, Eugene Alvin Villar <seav80 at gmail.com> wrote:
> > > Ok then. I'm all for tagging barangay center nodes with
> > place=barangay. We
> > > can just ask the renderers to place a special code to render
> >
> > place=barangay
> > > same as place=village.
> > >
> > > On Mon, Nov 24, 2008 at 4:29 PM, maning sambale
> > > <emmanuel.sambale at gmail.com>wrote:
> >
> > >
> > >> Hi,
> > >>
> > >> I am sending a discussion we (me and IanHaylock) had before with
> > Mike
> > >> Collinson (no talk-ph at that time) on tagging Barangays this in
> > the
> > >> context of when we are planning to import the GNS data.
> >
> > >>
> > >> For your comments
> > >> =======
> > >> Thanks for all the
> > input. Here is a modified version of the script
> > >> with PPL mapping to village not town. As is, it also reads the
> > entire
> > >> rp.txt file but only outputs DCG=ADM2 POIs. The resulting file,
> > also
> > >> attached is exactly the same as the one you sent me but has an
> >
> > >> addition 'is_in:state=' tag. I am very keen to get lots of
> > 'is_in'
> > >> tags into the OSM database as it will make future searching much
> > >> easier. For example, if there is a critical mass of entries for
> >
> > >> Aurora Province spread across the province, it will be possible to
> > >> work out the approximate bounds of the province and limit searches
> > >> there. That removes the need to have exact boundary data.
> >
> > >>
> > >> Do upload it if you think it is ready.
> > >>
> > >> On the issue of PPL = village or barangay or locality, these are my
> > >> thoughts.
> > >>
> > >> I suggest
> > we definitely do not use 'locality', that is really
> > meant
> > >> for place names that do not coincide with any (current) population
> > >> centre.
> > >>
> > >> place=village
> > >>
> >
> > >> Plus: Works worldwide. Minus: Not strictly valid in a Philippine
> > context.
> > >>
> > >> place=barangay
> > >>
> > >> We'd need to get the OSMarender and Mapnik guys to add a render
> >
> > rule
> > >> for this. We could also ask for it to be added as a Map Features
> > >> value, but that is not strictly necessary. I'd guess the easiest
> > >> request would be to say, "please render this exactly the same as
> >
> > >> place=village"?
> > >>
> > >>
> > >> If I was explaining what Barangay means, does this sound right? :-
> > >>
> > >> place=barangay is specifically for Philippine use, though may be
> >
> > >> applicable in other parts of the world like South America. At
> > an
> > >> administrative level, a Province (= a state) is divided into
> > >> muncipalities. Each municipality is controlled by a local council
> > and
> > >> has a mayor. A municipality is split into barangays[1], headed by
> >
> > >> Barangay captains. In rural areas, these equate to villages. In
> > urban
> > >> areas, these equate to suburbs often highly distinguishable on the
> > >> basis of social class. A rural muncipality, e.g. Donsol[2], may
> >
> > >> therefore have a town, Donsol, split into 3 or 4 barangays and
> > then to
> > >> It is important to mark them on OSM maps because they are used
> > >> extensively in every day navigation, information, politics etc.
> > They
> >
> > >> almost invariable equate to an obvious population centre (unlike
> > >> European wards). Street signs often show which barangay they are
> > in.
> > >> Jeepneys and buses often show a barangays as
> > destinations.
> > >>
> > >> [1] http://en.wikipedia.org/wiki/Barangay
> > >> [2] http://en.wikipedia.org/wiki/Donsol
> >
> > >> ==============
> > >>
> > >>
> > >> On 11/22/08, Eugene Alvin Villar <seav80 at gmail.com> wrote:
> > >> > Hi Zoren,
> > >> >
> >
> > >> > On Sat, Nov 22, 2008 at 6:12 PM, <sorabsuperstar at web.de>
> > wrote:
> > >> >
> > >> >>
> > >> >> > There's no discussion yet regarding barangays. I
> >
> > prefer leaving out
> > >> >> > the "Barangay" part of the name (unless
> > it's numeric like "Barangay
> > >> >> > 30").
> > >> >>
> > >> >> I was just about to send a second mail about that, as I
> >
> > realized that
> > >> >> at
> > >> >> certain zoom levels you can hardly see the map anymore
> > because of all
> > >> the
> > >> >> Brgy. names, or hardly see certain Brgy
> > names because of the
> > other Brgy
> > >> >> names ;).
> > >> >> I guess the Brgy concept is a special Pinoy one. This is why
> > the
> > >> renderes
> > >> >> are not designed for such a high density of area names
> >
> > (especially with
> > >> >> regard to font sizes) . To ease this problem I highly
> > endorse Seav's
> > >> >> suggestion to omit redundant words "Barangay",
> > "Brgy."(anyway for being
> >
> > >> an
> > >> >> abbreviation), "Village",
> > "Subdivision"etc...; unless it is really part
> > >> of
> > >> >> the name as in "Barangay 30".
> > >> >> We should even make this a general national convention for
> >
> > OSM
> > >> >>
> > >> >
> > >> > Regarding this, do not be too conscious of the rendering
> > problems. Try
> > >> not
> > >> > to "fix" the data just so it would render pretty. The
> >
> > important thing
> > is
> > >> to
> > >> > do the data right and just leave the renderers (Mapnik,
> > Osmarender,
> > >> > etc.)
> > >> to
> > >> > decide how to best present the data.
> > >> >
> > >> > Eugene / seav
> >
> > >> >
> > >> > --
> > >> > http://vaes9.codedgraphic.com
> > >> >
> > >>
> > >>
> > >> --
> > >> |---------|--------------------------------------------------------
> > --|
> >
> > >> | __.-._ |"Ohhh. Great warrior. Wars not make one great."
> > -Yoda |
> > >> | '-._"7' |"Freedom is still the most radical idea
> > of all" -N.Branden|
> > >> | /'.-c |Linux registered user #402901, http://counter.li.org/
> >
> > |
> > >> | | /T |http://esambale.wikispaces.com/ |
> > >> | _)_/L I http://epsg4253.wordpress.com/ |
> >
> > >> |---------|--------------------------------------------------------
> > --|
> > >>
> > >
> > >
> > >
> > >
> > --
> > > http://vaes9.codedgraphic.com
> > >
> >
> >
> > --
> > |---------|----------------------------------------------------------|
> > | __.-._ |"Ohhh. Great warrior. Wars not make one great." -Yoda
> >
> > |
> > | '-._"7' |"Freedom is still the most radical idea of
> > all" -N.Branden|
> > | /'.-c |Linux registered user #402901, http://counter.li.org/ |
> >
> > | | /T |http://esambale.wikispaces.com/ |
> > | _)_/L I http://epsg4253.wordpress.com/ |
> > |---------|----------------------------------------------------------|
> >
> >
> >
> > _______________________________________________
> > talk-ph mailing list
> > talk-ph at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-ph
> >
> >
> >
> > _______________________________________________
> > talk-ph mailing list
> > talk-ph at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-ph
> >
> >
> >
> >
> > --
> > http://vaes9.codedgraphic.com
> >
> > _______________________________________________ talk-ph mailing list
> > talk-ph at openstreetmap.org http://lists.openstreetmap.org/listinfo/
> >
> > talk-ph
>
>
>
--
http://vaes9.codedgraphic.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ph/attachments/20081125/57984f9e/attachment.html>
More information about the talk-ph
mailing list