[Talk-ko] Talk-ko Digest, Vol 25, Issue 1

[Andrew Errington]

Hi Brian,

Is there some way that you can process the data before you use it?  For 
example, if you want 'English' fetch all the name tags for everything in the 
area you are interested in and then overwrite name=* with the contents of 
name:en (if present), then pass the data on to the GPS (or phone, or map 
drawing program).

Best wishes,

Andrew


On Sun, 20 Jan 2013 21:36:45 Brian McLaughlin wrote:
> Robert,
>
> Thanks for your quick reply and useful insight. Good Idea to use an extra
> space between the Hangeul and Roman characters to give the text a little
> extra buffer. I did mean to leave a space, but maybe two spaces are better.
> As far as the suffix translations go, I was just throwing that out there. I
> could care less about that. I would be happy to leave the name:en as is. I
> don’t want to make things more complicated than they have to be. That tag
> isn’t even rendered anyway.
>
> I’m most concerned with the generic name tag, since it makes the labels
> really hard to read on my GPS and hand phone, and if puts unnecessary
> characters on my paper maps. Plus I think it makes the slippy map a little
> cluttered too. Hopefully I can get some more feedback from others. I don’t
> want to rock the boat and start changing accepted conventions with just
> cause and peer support.
>
> Safe and Happy Mapping to you too,
> Brian
>
>
>
> Andrew ,
>
> Thanks for your quick reply and support.
>
> Thanks for your support. I checked out the link and when they get it
> working that will be great. But it’s not really feasible for me to
> implement. It would take a very powerful server with lots of bandwidth and
> disk space to make that work with my project. However, as long as we tag
> our features correctly, I’m sure whatever we do will compatible with their
> project. I personally think it’s useful to have both the Hangeul and roman
> names rendered together.
>
> As far as the Multilingual Map Project, I have a good idea how they did it.
> I’m guessing that first they rendered their own tiles without labels, and
> then they are overlaying them with vector labels from a separate database.
> Currently when you look at OSM and other web maps such as Google and Naver,
> what you are seeing is a collection of georeferenced  .png images. The
> technology works great, but you can’t change the variables once they’re
> rendered. In a few years I’m sure the technology will be available to
> effectively deliver the same data in vector format allowing users to
> customize the rendered images to their own liking. But that’s going to
> require some pretty powerful servers and lots of bandwidth to work.
>
> Brian