Re: [OSM-talk] Russian community mailing list

[Komяpa]

Hi,

Russian community lives on forum and telegram. http://t.me/ruosm and
https://forum.openstreetmap.org/viewforum.php?id=21

On Sun, Aug 25, 2019 at 3:55 PM dcapillae  wrote:

> Hi.
>
> What's the Russian community mailing list? I tried to subscribe to
> "talk-ru"
> [1] but I can't do it. The last message in the archive is March 2015. Is
> there another list?
>
> Thank you. Greetings from Spain.
>
> Regards,
> Daniel
>
> [1] https://lists.openstreetmap.org/listinfo/talk-ru
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] English wiki displaying partial alternate language

[Komяpa]

Please click on the wiki UI selector and not a link inside page:
[image: image.png]

On Thu, Jul 11, 2019 at 4:46 PM Dave F via talk 
wrote:

> On 11/07/2019 14:18, Upliner wrote:
>
> Do you see language switcher at the top near user name? Just select English
> there and all will be fine.
>
>
> Do you see 'English' is in *bold *meaning it's already selected?
>
> DaveF
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Komяpa]

Hi,

We've updated http://disaster.ninja/live/ to use fresh 2019 release of GHSL
dataset.
Mountains in Switzerland aren't populated anymore. Chinese mountain regions
are also better detailed.

Have a good day!

Darafei
Kontur.io

On Sun, Jul 7, 2019 at 3:23 PM Christoph Hormann  wrote:

> On Sunday 07 July 2019, Darafei "Komяpa" Praliaskouski wrote:
> >
> > We're using GHS population grid in Switzerland.
> > https://ghsl.jrc.ec.europa.eu/data.php
> > Methodologically, they use radar data to find "houses". It means on
> > their dataset people also live along roads with asphalt, and - may
> > happen - bare rocks are also populated. You can drop them a line on
> > jrc-ghsl-d...@ec.europa.eu to say thanks.
>
> I am familiar with that data - they use census based or otherwise
> estimated population numbers per admininstrative unit and distribute
> this population among areas they identified as "built-up" using rather
> questionable processes (what we in German tend to describe
> as "Kaffeesatzleserei").  There is no identification of houses - source
> data used is way too low resolution for that.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Komяpa]

Thank you!
Will keep publishing :)

On Mon, Jul 8, 2019 at 2:56 PM Sérgio V.  wrote:

> Excelent and inteligent initiative Darafei.
> Measuring "density of OSM data" per "Population density" is a powerful
> metric to analyse where is it lacking more mapping in OSM.
> It's a nice effort to minimize "inequality" in OSM map.
> (for more info, see "World Inequality Database" at https://wid.world/world
> )
>
> I've did that metric for Brazil in 2017, "Demography in Brazil to help
> mapping in OSM", at:
>
> https://wiki.openstreetmap.org/wiki/Demografia_do_Brasil_como_auxiliar_no_OSM
> It helped me much to find places lacking mapping.
> Everytime I just take a fast look at the highlighted places int that map,
> I've actualy found undermapped places, lacking roads mostly.
>
> These metrics lead to view two aspects:
> a) By one hand, the world is in a fast urbanizing process. People more and
> more migrate to bigger cities, looking for better jobs, services, better
> life.
> According to United Nations report, "68% (2/3) of the world population
> projected to live in urban areas by 2050" (UN 2018-05-16 -
> https://www.un.org/development/desa/en/news/population/2018-revision-of-world-urbanization-prospects.html
> ).
> So, it's generally expected to have a lot of irregular setlements to map
> in broader urban areas. Even benig irregular, millions of people live in
> such places.
> b) By the other hand, people remaining in country sides become more alone
> (many times old people), living far away from good public services and
> enough incomes, broadly unassisted. So also important to map their
> accessibility.
>
> Don't matter with objections for too much fine precision on demography.
> That metric anyway gives much more reasonable focus than usual
> over mapping done in OSM.
> Nice, keep going, publish it.
> Regards
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Komяpa]

On Sun, Jul 7, 2019 at 3:46 AM Pierre Béland  wrote:

> Speaking more generally,
> Populatation is growing fast in Africa and many african countries dont
> have the resources to organize regular census. See the UN Statistics
> Division record of last census by country
> https://unstats.un.org/unsd/demographic/sources/census/censusdates.htm
>
> This means that quality vary from one country to the other and that often
> we lack good info about distribution of population in the various
> countries.  The OSM building mapping projects are often used for population
> estimates.
>

This is exactly the reason we threshold the visualization into just three
population classes: population dataset behind it is using classified
satellite imagery multiplied with census counts.
We're not much interested in exact population counts for this task, rather
whether there's something on satellite that's worth inspecting and probably
mapping.

Darafei Praliaskouski
Kontur.io
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Komяpa]

On Fri, Jul 5, 2019 at 3:42 PM Christoph Hormann  wrote:

> On Friday 05 July 2019, Darafei "Komяpa" Praliaskouski wrote:
> >
> > http://disaster.ninja/live/
> > <http://disaster.ninja/live/#overlays=alert-shape-GDACS_EQ_1183112_12
> >65046,bivariate_class;id=GDACS_EQ_1183112_1265046;layer=default-style;
> >position=-13.88712117940031,30.076044779387132;zoom=2.4760319802318693
> >>
> >
> > What do you think?
>
> Are your densities in people/object per ground square kilometers or per
> mercator square kilometers? (just to be sure - this is the number one
> mistake of any kind of density analysis in the OSM context)
>

These are ellipsoid based square kilometers. I also dislike when
visualizations fade out to the poles :)



> One warning:  All global population data sets that exist are rough
> estimates with usually significant systematic biases and errors.  For
> example in Switzerland the data set you used sees high population
> density in mountain areas with no basis in reality.
>

We're using GHS population grid in Switzerland.
https://ghsl.jrc.ec.europa.eu/data.php
Methodologically, they use radar data to find "houses". It means on their
dataset people also live along roads with asphalt, and - may happen - bare
rocks are also populated. You can drop them a line on
jrc-ghsl-d...@ec.europa.eu to say thanks.

Is there a better resolution population dataset for Switzerland?

To fix it we can get "unpopulated areas" polygons from OSM. I see that
forest, fields, water, quarry are likely candidates to be used to mark
population as zero, if no buildings are present in OSM. What tagging would
be used for unpopulated mountain?



> And i am not a fan of deliberately pixelated visualizations where the
> data is shown in a pixel grid at a coarser resolution than what the
> display offers.
>

Can you point to a better visualization which we can learn from?
Map is supposed to be used on settlement level, where our grid is "4 pixels
per screen" - to highlight a settlement without trying to predict its
boundaries.


> Apart from that this is an interesting analysis.  It would be kind of
> nice to also do it separately for density of features that actually
> correlate with population density in reality (buildings, roads,
> addresses, shops etc.) and physical geography, which can be mapped just
> as densely in areas with no population as in densely populated areas.


We've built such map initially, and it's not significantly different from
this one in disaster mapping perspective. People don't map physical
geography far from their home much in OSM, and large unmapped regions don't
become more mapped if we lower feature counts in more mapped regions.
Note that any large multipolygon is counted as just 1 feature here.


Darafei Praliaskouski
Kontur.io
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Komяpa]

Hi,

On Fri, Jul 5, 2019 at 4:09 PM Jean-Marc Liotier  wrote:

> On Fri, July 5, 2019 2:40 pm, Christoph Hormann wrote:
> >
> > One warning:  All global population data sets that exist are rough
> > estimates with usually significant systematic biases and errors.  For
> > example in Switzerland the data set you used sees high population
> > density in mountain areas with no basis in reality.
>
> Same in rural Senegal. Low-resolution population data I guess.
>

Can you point to a specific place please?

What would be the population dataset that you would recommend for Senegal?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Map of Population Density vs. OpenStreetMap density

[Komяpa]

Hi,

In HOT mailing list I was advised to bring a part of a thing we did to
wider audience :)

We've correlated global population datasets with plain OpenStreetMap
objects count. The main use case is to quickly determine how much is there
to map in case of natural disaster in a smaller region, but the map itself
is global - it's interesting to see what's around you and find the spots to
map next, even outside of the disaster.

http://disaster.ninja/live/


What do you think?

(The HOT list thread if you are interested in disaster.ninja tool itself:
https://lists.openstreetmap.org/pipermail/hot/2019-June/014908.html)

Darafei Praliaskouski
kontur.io
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Which global OSM mailing list for the "community index"?

[Komяpa]

Frederik,

Feel free to add both. With a proper description it won't hurt.

On Thu, Jun 20, 2019 at 2:43 PM Andy Townsend  wrote:

> On 20/06/2019 11:46, Mike N wrote:
> > On 6/20/2019 5:58 AM, Frederik Ramm wrote:
> >> Clearly one of the global mailing lists is missing here;
> >
> >   Forum.openstreetmap.org
> >
> "talk" probably gets more pairs of eyes on it than the Q subforum
> https://forum.openstreetmap.org/viewforum.php?id=10 (which is probably
> the nearest equivalent).  Both require registration with something that
> new participants already have (an email address in one case; some OSM
> login credentials in the other).  Both have had similar numbers of posts
> today.
>
> Some people will prefer forums to mailing lists, some vice versa; why
> not suggest both?
>
> I'd suggest "talk" as a more sensible introductory mailing list to
> "tagging" as the latter is higher volume and more in depth in a
> particular area of OSM.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Anyone who likes to organize an ID discussion panel at SotM?

[Komяpa]

>
> Underneath the specific issues with iD development that are being
> discussed right now lies a broader problem of ideas of cultural
> exceptionalism
>
...

I believe the problem is much simpler. iD is not developed by employees of
OpenStreetMap Foundation so there is no formal way to ask anything from its
developers. It is an independent project that never took oath "support but
not shape the project", so it is going to shape it. Can there be an
official editor from OSM Foundation with actual developers behind it
though, with current financial governance model?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Board decision on Crimea complaint

[Komяpa]

Hi Frederik,

Can there be a transparency on death treats too?

On Tue, Dec 11, 2018 at 1:42 PM Frederik Ramm  wrote:

> Hi,
>
> On 11.12.2018 11:16, Andrew Hain wrote:
> > A question both to the current board and the candidates: Do you support
> > normal levels of Board transparency on this issue?
>
> Just as a "data point" in this discussion: There are people out there
> who are happy to issue death threats to anyone who is seen to be
> deciding something not in their favour.
>
> I'm not saying that this should automatically top any transparency
> requirements, and there hasn't been a board decision to limit
> transparency about this, but when discussing transparency in matters
> like this you have to take into account that transparency *can*
> occasionally mean that bullying becomes easier, and that people who
> would otherwise have voted yes or no suddenly vote abstain just to keep
> out of trouble.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Distribution of OSM ids could be much more useful!

[Komяpa]

If you agree that tile id is assigned only upon creation, then you don't
have to remove the history for moved or existing nodes.

Also, Google S2 gives much more standard globe locality index, if you need
a look up table.

You can try getting a pull request with the change through railsport and
cgimap maintainers though, as they are the only people limiting pace of
openstreetmap api development :)

On Sun, Nov 25, 2018 at 4:53 PM Victor Shcherb 
wrote:

> Hi All,
>
> As we know OSM id for nodes exceeded long time ago 2^32 and keep growing
> on the other hand the ids itself are pretty useless because they don't
> represent history good enough and also they couldn't implement principle of
> Permanent ID (https://wiki.openstreetmap.org/wiki/Permanent_ID).
>
> I suggest to discuss geometrical value of OSM id per node. Of course there
> is ongoing discussion to attach OSM nodes to ways, so the number of nodes
> will decrease dramatically but that's a long-mid term strategy. Much easier
> is to give some value to OSM ID.
>
> PROPOSAL. Dedicate 30 bits of OSM ids to the quadrant of the Globe (per
> square radiant) i.e. last *30 bits *of the ID could represent *15th zoom
> of globe radiant tile *(not Mercatoor projection tiles).
>
> What's useful.
> 1. Programs to import OSM could process it much faster cause id in the
> ways could indicate where physically the way is located.
> 2. Programs that store IDs could store much more compressed i.e. OsmAnd
> maps could benefit for storing maps in QuadTile structure and keep only
> part of id attached to QuadTile
> 3. It is a step forward to compress the data and have formats for faster
> processing and better storage.
> 4. Probably something more?
>
> Why it is easy to implement.
> - Doesn't require to change anything in the schema and in the tools
> - Most likely doesn't require to change any editor cause the changes could
> be postprocessed by the changeset commiter.
> - *Backward compatible!* Old ids before the given number could stay the
> same for a while.
>
> Challenges / Objections.
> - If you move a node from its original tile the history will be lost and
> id will be changed (I doubt it is a strong objection cause information
> could be partially / visually restored from changeset history).
> - The uploading changeset from editor could differ from result changeset
> stored in OSM API.
>
> What do you think?
>
> Best Regards,
> Victor
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

[Komяpa]

Hi Nick,

osm2pgsql is tolerant to features absent in database. You can in theory
even start with empty set of tables and just insert new diff data.

Usually people also clip minutely osc, as per day database grows by a small
country otherwise.

чт, 8 нояб. 2018 г. в 17:37, Nick Whitelegg :

>
> ... sorry, when I say "full planet extracts" I mean only England, Wales,
> Scotland, Ireland (all) and Greece - not the entire planet.
>
>
> Thanks,
>
> Nick
>
> --
> *From:* Nick Whitelegg
> *Sent:* 08 November 2018 14:34:17
> *To:* osm-talk
> *Subject:* osm2pgsql diff application with filtered OSM data
>
>
>
> Hi,
>
>
> Looking towards overhauling the import system I use for my Freemap site (
> free-map.org.uk) which is itself going to go through an overhaul in the
> near future by moving to Tangram and hopefully applying hill shading.
>
>
> At the moment I download full planet extracts about every 6 months.
> However, due to the limitations of my server, I filter out (with osmosis) a
> lot of stuff I don't need so that I am basically left with roads,
> footpaths, natural features, water features and selected POIs.
>
>
> I'd like to move towards a system which applies diffs from geofabrik
> instead, and applies them regularly (daily or weekly) with osm2pgsql.
>
>
> My question is this; given that not everything in the diff will be in my
> database (as I filter out what I don't need during the import process),
> will osm2pgsql apply the diff successfully or will it complain that not all
> features in the diff are in my database?
>
>
> Thanks,
>
> Nick
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=* + area=yes vs area:highway=*

[Komяpa]

area:highway= to highway= is what waterway=riverbank to waterway=river.

The first is area used to understand the curvature of the edge, the second
is a routable way. They denote different things and aren't interchangeable.

As with rivers, it's expected that lines are mapped first, and on top of
those detailed polygons are overlaid later.


ср, 8 авг. 2018 г. в 20:11, djakk djakk :

> A linear road is also a surface, the surface is useless at zoom=8 but
> useful at zoom=16.
> Like waterways, both can coexist.
>
> djakk
>
>
>
> Le mer. 8 août 2018 à 18:19, Tobias Knerr  a écrit :
>
>> On 08.08.2018 12:49, Tomasz Wójcik wrote:
>> > Due to our rules, that we shouldn't have 2 active tagging
>> > schemes for the same feature
>>
>> These tagging schemes are for 2 different real-world features:
>> * roads/paths (i.e. linear features with a direction)
>> * plazas/squares (i.e. open areas where people will walk across in all
>> directions)
>>
>> Linear roads/paths are mapped as highway=* ways, optionally with an
>> additional area:highway=* polygon.
>>
>> Plazas/squares are mapped as highway=* + area=yes polygons.
>>
>> So the area:highway key is never an alternative to highway polygons with
>> area=yes! In any given situation, only one or the other will be correct.
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Paper/Article about stagnation in OSM

[Komяpa]

> Then when we call in browser something like: osm.org/?address=hj3u878s



This is already on website and available at "share - short link":
https://osm.org/go/0lrHA3xsZ


-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM Rendering Server

[Komяpa]

Hi,

Since September 2016 I've been sponsoring a rendering server for OSM tiles
called `vial` out of personal finance. It is set up on Hetzner. This month
Belarus tax regulations changed, and Hetzner starts charging 20% more from
Belarus residents.

If somebody is willing to take the flag of sponsoring this machine, drop me
a line and I'll transfer server to your account. I'll stop it in July
otherwise. Monthly fee is 144.2 EUR now.

If you're willing to set up another server (cheaper or on bigger hardware)
side by side, have a look at Hetzner's Server Bidding - you can find
similar machines, without setup fee. Try getting smaller machine with
SSD+HDD and setting SSD as caching device for HDD - it's going to get
better performance than current Vial's setup (which spends lots of time
waiting for HDD).

More on how to provide a server for OSM:
https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN

Thanks.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Komяpa]

Hi,

maps.me took approach similar to Nominatim's: each map region has "default
language" in metadata, and in case the name: is
needed but is missing, just name tag is taken.

Similar approach was used when making a map for Wargaming's World of Tanks,
looking at the country's iso code. A list used there is available on github,
https://github.com/wgnet/globalmap/blob/master/data/country_languages.csv

(Translations that OSM lacks were performed by professional translators and
also published under ODbL,
https://github.com/wgnet/globalmap/blob/master/data/wgnl_localizations.csv,
and for non-critical map labels we've trained anything-to-latin and
anything-to-cyrillic neural networks, results
https://github.com/wgnet/globalmap/tree/master/data/rnn).

ср, 25 апр. 2018 г. в 9:23, Mateusz Konieczny :

>
> 24. Apr 2018 21:29 by rich...@systemed.net:
>
> If I read Frederik's proposal right, the language=en tag would be placed on
> the object with the name tag
>
>
> Interesting idea, I like it. Is there already a page on the OSM wiki
> describing this proposal?
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Nominatim on the main page

[Komяpa]

>
> Have a look at the OSMF board, a mixed bunch of people elected by the
> members. Are you sure that a seasoned developer or sysadmin would even
> *want* a paid job where they are subject to the whims of an elected
> board, with a potentially modified "strategy" year after year (as
> majorities change due to new elections)? Would that not be a job like
> Dilbert's with his pointy-haired boss?
>

Would such a person take this position voluntarily and unpaid?

Existing stable devs and sysadmins are paid with "unlimited power" in the
project now. Is that a good thing? If we get more devs/sysadmins "for
free", we're splitting the "unlimited" into halves effectively making it
limited and much less appealing. Can we replace "a free unlimited power"
payment we give to dev/sysadmins now with any other scalable means, be that
money or anything other?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roundabouts - why is a separate segment required?

[Komяpa]

>
>
> To repeat myself. You can determine if you need to "drive on this round
> way" from a single node. No need for a section between entrance & exit.
>

You can. You're at it now.
Someone else can be thinking of all the other cases while implementing
their thing.

Sometimes people think "this is obvious, everyone will parse it that way",
and then find out that someone just checks oneway tag for non-empty and
their oneway=-1 are shown in reverse, and there's nothing you can do about
it.

You can either make an ambiguous scheme that allows two different
interpretations ("you enter roundabout the moment you touch the way" and
"you did not enter roundabout and it's just a turn") and have difficulties
counting exits. Or you can follow the suggestion, add a small segment and
make the data that can be understood in the same way by consumers with
different assumptions.

It's better to have compatible defaults.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Komяpa]

Hi,

Please don't try to save on keeping data in text format, this is a path to
removing source= tags and starting to use abbreviations in name for the
sake of file size, ignoring the fact that each object has much longer
iso8601 timestamp attached to it.

Use proper format, like .osm.pbf, that employs text strings compression,
binary representation of everything numeric and fixes the issue of 'spaces
around country code' and 'www.' by GZIPing the contents.

чт, 18 янв. 2018 г. в 14:03, Oleksiy Muzalyev :

> On 18.01.18 06:58, Mark Wagner wrote:
> > On Thu, 18 Jan 2018 06:14:17 +0100
> > Oleksiy Muzalyev  wrote:
> >
> >> Good morning,
> >>
> >> I started to experiment with the OSM data [1] on a local computer,
> >> and I begin to realize how big these data files are. It takes quite a
> >> while to load into the local database just the data for one country.
> >>
> >> What can I as a map editor do to keep these data files to a
> >> reasonable size without compromising  data quality? I mean in the
> >> sense, - take care of the pennies and the pounds will take care of
> >> themselves?
> >>
> >> I could think of the following three approaches so far:
> >>
> >> - using as short an URL as possible, website=http://somewebsite.com
> >> instead of website=http://www.somewebsite.com , three characters
> >> less; [2]
> >>
> >> - correct phone number ISO format, phone=+12 345 678 90 12 instead of
> >> phone=+12 (345) 678 90 12 , two characters less;  [3]
> >>
> >> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with
> >> consequent verification of its geometry;
> >>
> >> What else, if anything, could be done?
> > Honestly, the best thing you can do is not worry about it.  The world
> > is a big, complicated place.  The three bytes you save from shortening
> > a URL?  You'd need to repeat it 400 times to fit one extra gas station
> > on the map.
> >
> > As an experiment, I tried applying various data-saving
> > options to a park I've mapped.  I managed to reduce the size from
> > 1240354 bytes to 1218966 bytes for a savings of 1.7% -- savings that
> > will vanish almost instantly this spring once I resume mapping
> > seasonal wetlands.
> >
> Mark,
>
> You make sound 1.7% as not much, however, in say civil aviation or
> maritime industries, consistent 1.7% of fuel efficiency increase would
> be a breakthrough.
>
> I do not suggest, speaking figuratively, not breathing to save air. On
> the contrary, I think the mapping just begins, at least in some areas.
> So there will be much more, perhaps, times more data.
>
> At the same time, it would not harm to be mindful of data size issue and
> to follow simple best practices, as the shortest URL possible, the ISO
> phone format, etc.
>
> Best regards,
> Oleksiy
> osm: Alex-7
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] weeklyOSM #388 2017-12-19-2017-12-25

[Komяpa]

Dear Weekly OSM Team,

Is there a way to read you round-up of OSM news in text of email, not only
as a link to site?

This may bring more discussions to talk@ and raise awareness of things
happening in OSM world :)


сб, 30 дек. 2017 г. в 14:42, weeklyteam :

> The weekly round-up of OSM news, issue # 388,
> is now available online in English, giving as always a summary of all
> things happening in the openstreetmap world:
>
> http://www.weeklyosm.eu/en/archives/9819/
>
> Enjoy!
>
> weeklyOSM?
> who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
> where?:
> https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM tagging validation lib

[Komяpa]

Hi,

What language would that library be in, if level0 and iD are in javascript,
JOSM and Vespucci are in Java, and many random console tools are in python
and perl?

It would be cool to have such library running on osm2pgsql import, fixing
and complaining/skipping all the mistaked tag usage it can detect. This can
possibly resurrect some objects that are lost because of typos or old
tagging schemes.

вс, 24 дек. 2017 г. в 14:12, François Lacombe :

> Hi
>
> Here is an idea I got regarding tagging validation in editors (iD, JOSM,
> others).
> Subsequently to wiki proposal voting and cleanups, it's currently
> necessarily to open issues in each editor repository to ask for new tagging
> validation rules.
>
> It can sometimes be time consuming to develop those new rules and such a
> work is done independently by each project maintainer. While each project
> have its own specific components, background logic is the same.
>
> Would a new lib called like osmtagvalidator or so in charge of doing
> conform validation to wiki be useful?
> It may be shared by any project involved in osm editing and preserve its
> resources for other valuable developments.
>
> For me, validation doesn't prevent users to use tags they want, but only
> warn them about possible mistakes.
>
> How would devs and users feel about this?
>
> All the best
>
> François
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Effecting change in OpenStreetMap

[Komяpa]

вс, 19 нояб. 2017 г. в 1:11, Christoph Hormann :

> On Saturday 18 November 2017, Ilya Zverev wrote:
> > john whelan wrote:
> > > No you need to build up trust again and it takes time.  Only then
> > > will your ideas start to gain acceptance.
> >
> > Oh come on. I've been a mapper since 2010, I've hosted dozens of
> > events, I've written many articles and tools, some of which you might
> > have used, I'm on the Board currently, and still my proposals and
> > pull requests fail again and again, because there is no trust in
> > OpenStreetMap. There is nothing you can to to build up trust. Your
> > ideas will never get acceptance, it's just nitpicking and "unwritten
> > rules" all over.
>
> I hope you are aware that with this you deny everyone who has ever
> voiced critique on any of your proposals and pull requests to have a
> competent opinion on the topic in question.
>

(sorry for my Russian straightness)

Many words, long story short: technology-wise, OpenStreetMap core is dead.

There is no development outside of a limited set of companies, and even
that is mostly aimed at profit of the company, not the OSM community. All
of it is done in "consumer" role.

People trying to gain knowledge of developing something in non-"consumer"
paradigm get shamed all over mailing lists. Or have a look what it takes to
launch any kind of popular OSM editor, be it Potlatch or Maps.me, in terms
of amount of hate towards you.

It is impossible to get anything merged into core infrastructure. If
initial author stepped away from the project, there is a group of ~5 people
who effectively say no to any change.

This year I got several PRs reviewed and merged into PostGIS, yet even
simple configuration/limit changes to openstreetmap.org get ignored.

I've posted a -dev mail about reusing nighttime of tile rendering servers.
Some likes on GitHub, some reviews from passer-by's, no merge, nothing
about "what to fix to get it merged". For a year. Patience you say?
https://github.com/openstreetmap/mod_tile/pull/152

/map call is technically 40x slower than it should be, but issue is being
closed with "we are not complete idiots" comments. No action taken wherever.
https://github.com/openstreetmap/operations/issues/135

"I'm worried about this. I have not performed a technical review." as a
blocker for PR merge:
https://github.com/gravitystorm/openstreetmap-carto/pull/2939

Basically, most of wide ~2011 dev community was hired away, and core is in
hands of those who weren't hired away by Map* for whatever reason, be that
lack of social skills or lack of technical skills. You've got no fresh
blood, and there's no road map for it to improve.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] a sample panoramic aerial image for 3D mapping made with the new DJI Spark quad-copter

[Komяpa]

We're using DJI Mavic ($1000), Pix4D Capture application and Pix4D
($300/mo) to get orthorectified imagery in Belarus. It takes 1 battery, 20
minutes of flight time and several hours processing to get 1x1 km chunk in
6 cm/px.

Sample:
https://cloud.pix4d.com/pro/project/169316?shareToken=9fda4c2a6fc64b938886d3f4fa477692


DSM and 3D is also generated.

We upload it to OpenAerialMap. There are some issues in their pipeline that
make imagery not very crisp:
https://github.com/hotosm/oam-dynamic-tiler/issues/49


пт, 1 сент. 2017 г. в 18:42, Oleksiy Muzalyev :

> On 9/1/2017 5:12 PM, Martin Koppenhoefer wrote:
>
>
>
> 2017-09-01 16:24 GMT+02:00 Oleksiy Muzalyev :
>
>>
>> But the advantage is that it weighs only 300 grams, very portable, and it
>> is ready to fly almost instantly as folding propellers are fixed
>> permanently, and smart-phone connects to the remote control via WiFi, no
>> cables are necessary.
>>
>
>
> did you try how high/far you can get before loosing the wifi connection?
>
> Cheers,
> Martin
>
> Hello Martin and James,
>
> In this case was talking about Wi-Fi connection between smart-phone where
> runs DJI Go 4 app and the remote control radio, they remain close to one
> another all the time. But certainly the flight range of Spark is not as
> great as the one of the Phantom.
>
> There is a list of compatible smart-phones for the Spark at the very
> bottom of this page: http://www.dji.com/spark/info#specs . I read at the
> DJI forum that if one uses such a smart-phone the range is better.
>
> I flew Spark maximum about 700 meters away and 150 (legal limit for the
> region) meters high. The video & control signals was present all the time,
> though my old smart-phone is not in the list. I ordered already a
> compatible one.
>
> For me this range is OK. The best aerial photos are made from the altitude
> of 70 - 100 meters anyway, and besides in accordance with the regulations
> it is allowed to fly only LoS (line-of-sight) anyway (unless there is a
> special license).
> The Spark remote controller has got folding outside antennas, so the range
> of several hundred meters, or I would guess up to 1 - 1.2 km, is probably
> due to these antennas. The range of the Phantom is more than 2 km.
>
> Best regards,
>
> Oleksiy
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Looking for "primary language" map

[Komяpa]

I once did country-to-language mapping for that.

https://github.com/wgnet/globalmap/blob/master/data/country_languages.csv

That repo also contains other stuff we implemented for displaying
multilingual map.

вт, 11 апр. 2017 г. в 4:10, Yuri Astrakhan :

> I simply need to determine the most likely language of the "name" tag (not
> the "name:xx" tag). Does not have to be 100% correct - even 80% is great.
>
> On Mon, Apr 10, 2017 at 8:59 PM john whelan  wrote:
>
> Orleans is part of Ottawa and all street names signs are bilingual or in
> the process of being replaced by bilingual ones.  Certainly the street I
> live on in Orleans has a bilingual street name sign.  The English French
> question is very much political in Canada and I suspect much of the world.
>
> Montreal has a quite large English speaking community which is rare in
> Quebec.
>
> You could try looking at the street names to see if they are in English
> and have a second language name as well. name:fr for example.
>
> Cheerio John
>
> On 10 April 2017 at 20:47, James  wrote:
>
> Well it might not be as simple as you say...take for instance Ottawa. It's
> in Ontario and pretty english. There is a suburb called Orléans in which is
> pretty much "the french part of town" as most street signs will be in
> french, but rest of Ottawa is pretty English(in terms of street signs)
>
>  So generilizing wont help you much...
>
> On Apr 10, 2017 8:27 PM, "Yuri Astrakhan"  wrote:
>
> Exactly, and that's the map I need -- a set of shapes that define these
> region mapping: Quebec+New Brunswick => fr, the rest of USA/Canada => en,
> ...
> The shapes may overlap because that would make geojson smaller - I will
> simply use the first one.
>
> Having this map will allow me to determine the likely language of the
> "name" tag for any location, which in turn make for a better multilingual
> map.
>
> On Mon, Apr 10, 2017 at 8:20 PM James  wrote:
>
> Well many countries have multiple official languages, Canada is French and
> English, but in practice is mostly Quebec and New brunswick...with small
> patches of french throughout the rest
>
> On Apr 10, 2017 8:12 PM, "Yuri Astrakhan"  wrote:
>
> James, thanks, but I was hoping for the language regions shapefile, e.g.
> in the GeoJSON form.  The list of official languages will require a lot of
> work to convert into the merged shapes, and it still not very good, as many
> countries have several official languages, e.g. Switzerland.
>
> On Mon, Apr 10, 2017 at 7:55 PM James  wrote:
>
> Also have you checked:
> https://en.wikipedia.org/wiki/List_of_official_languages_by_country_and_territory
>
> On Apr 10, 2017 7:50 PM, "James"  wrote:
>
> More like French for the entirety of the province of Quebec
>
> On Apr 10, 2017 7:38 PM, "Yuri Astrakhan"  wrote:
>
> Does anyone know of an open source language map - basically a set of
> geoshapes with the corresponding language code?  Country boundaries are not
> needed - e.g. Canada and USA would be English with the exception of French
> for Montreal area.
>
> This is needed to guesstimate what language the "name" tag is in.
>
> Does not have to be very precise (10-20 MB is more than enough)
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Cleanup of Wiki Page "Contact_channels"

[Komяpa]

Hello,

I've started to pull together the comprehensive machine-readable list of
the means of contact used through the community.

Let's map the internal communications :)

https://github.com/Komzpa/osm-contacts/blob/master/contacts.json

How you can help:
 - if you speak javascript, make a viewer/stats on it (d3 graphs anyone?);
 - help marking countries and languages there;
 - make records for forum.openstreetmap.org subforum;
 - update user counts on each chat;
 - if you thought of another chat, forum, list or whatever - just add it
there.

вт, 13 дек. 2016 г. в 0:38, Simon Poole :

>
> We are all reluctant to delete stuff in the wiki, but every page creates a
> maintenance burden that we simply, realistically, can't carry (not even
> starting ranting about translations). How likely is that anybody ever uses
> the page? Unluckily I believe we don't have  any page stats so we don't
> really have any data on what we can throw away. That doesn't mean that I
> want to reduce the tag documentation, quite the contrary, but at least that
> is self limiting in that we don't have endless variants of the same
> contents, all out of date and rarely viewed by anybody.
> Simon
>
>
> Am 12.12.2016 um 22:03 schrieb Michael Reichert:
>
> Hi Simon,
>
> Am 12.12.2016 um 21:47 schrieb Simon Poole:
>
> Like so many wiki pages there is really only one good action: send it to
> the circular folder.
> https://www.openstreetmap.org/help already lists all OSMF operated
> services, and at SOTM we discussed that we might add in one way of the
> other a pointer to the preferred national comms channel. Lets simply
> keep that up-to-date.
>
>
> This means that I should tidy up this wiki page by deleting almost
> everything, writing a few new words and adding thick, big link 
> tohttps://www.openstreetmap.org/help? Before I do that, I will write a
> pull request to the website to add the missing information at osm.org/help:
> - link to bugtrackers (I will write it like "to report software bugs of
> the website and other software)
> - notes (to name a method to inform us about map errors)
> - changeset discussion (to discuss a single map change somebody did)
>
> Best regards
>
> Michael
>
>
>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is tile rendering having a crisis?

[Komяpa]

>
> There was
> also a site using OSM tiles for a popular Pokemon Go map causing lots
> of additional traffic, once this was identified the site was blocked.
>

What was the site, and was it using OSM properly? (attribution, no evident
js bugs, etc)

What was the load?

How exactly Tile CDN should be scaled for this case to be handled not by
banning the site, but embracing their OSM usage?

I'm sure "to get this Pokemon Go site running bring us servers" could be
the way to solve it, making experience better not only for Pokemon Go
players but also for OSM mappers and users.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Can wikidata links help fight name inflation?

[Komяpa]

2015-06-07 14:43 GMT+03:00 Simon Poole si...@poole.ch:


 Two remarks on the the discussion:

 - the standard point: adding translations of names to OSM is (naturally)
 nonsense, adding names commonly in use in a language for places isn't. I
 somehow suspect that Frederiks suggestion is actually an attempt to
 offload the dealing with the nonsense aspect to wikidata.


This basically isolates the problem with understanding. Somehow you
distinguish names from translations.

There is an object. People in culture A call it A1, some of them call it
A2. People from culture B call it B1. People from culture C don't use
this object very often, but call it C1. People from culture D haven't
ever seen this object yet, but after first one of them sees it, he calls it
D2, but later scientists from culture D ask everyone to call it D1.
Object is located in a way so culture B lives around it.

So, in my perfect OSM world:

name = B1
name:B = B1
name:A = A1
alt_name:A = A2
name:C = C1
name:D = D1
alt_name:D = D2

note: name:B is there even though culture B surrounds it - think of
McDonalds in Belarus. It has name=McDonalds, even though usually objects in
BY have name= in Russian.

http://en.wikipedia.org/wiki/Translation says Translation is the
communication of the meaning of a source-language text by means of an
equivalent target-language text.
Translation is about giving some valid C1 given D2. The process of matching
is translation, not C1.

When I see text in Russian reffering Лондон, when I retell it to someone
English-speaking, I use London.
(then London is translation and should be removed from OSM as nonsense ;)

For geographical names there are different means that include
transcription, transliteration and adaptation of all kinds.
The fact that it can be thought to be automatizable to a certain degree
should not trick you into thinking oh, these aren't real names.

-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Can wikidata links help fight name inflation?

[Komяpa]

  You don't even need on the ground evidence. You just need someone with
 knowledge of Cyrillic and Roman alphabets to be able to transliterate
 Abergavenny into the Cyrillic, presumably.

 Transliteration is something that can be done at application level, and a
 traveller would have learned the basics. You still need to be able to check
 the street names against.what is on the sign.
 Then why not have a single transliteration?  A single cryllic to latin
 transliteration will serve all languages using the latin alphabet, do we
 need separate Russian,  Ukrainian,  Serbo Croat tags when they are
 identical?


Problem is, they are not identical. Russian, Serbian, Ukrainian, Belarusian
and other slavic languages have different alphabets, same way as Spanish,
German and Norwegian languages all have different letters.

Nowa Szkocja and Nova Scotia both sound the same, but are in different
languages. Same rules work across all the languages, just - sometimes -
they happen to look the same. In turn, looking the same does not guarantee
that these names sound the same.

What exactly are we trying to save by omitting these locales, what wasn't
eaten already by source= on French buildings? :)

-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Can wikidata links help fight name inflation?

[Komяpa]

2015-05-29 0:50 GMT+03:00 SomeoneElse li...@atownsend.org.uk:

 On 28/05/2015 22:27, moltonel 3x Combo wrote:

 You can argue against machine-made non-reviewed translitterations,
 because they don't add anything that a data consumer couldn't and
 because they likely contain mistakes. But that's apparenlty not the
 case of the name:ru changeset that got reverted.


 The source of the names in the reverted changeset is described in the
 changeset discussion http://www.openstreetmap.org/changeset/30451655 :

 to find russian names for places, I googled for English place names plus
 достопримечательности, погода or some other russian word.


Looks like you completely miss the point I'm native Russian speaker who
also speaks English a little bit.
I know how a russian would call that place the minute I see it.
Googling is a way to cross-check if my guess is valid - the corner case
about Slough was given a couple of letters above.

Some places with unusual pronounciation got their name:ru 5 years ago - why
weren't these reverted since then?

http://www.openstreetmap.org/node/21280555/history

Some live happily with name:he, name:lt and even name:ja, but name:ru was
removed from them repeatedly:

http://www.openstreetmap.org/node/10021976/history

I'm sorry to ask - isn't japanese tag there a transcription to hieroglyphs?
When I ask google translate to pronounce it, I hear what I would write in
cyrillic as Лестаар.
So, why was it kept?

I also see links to Name page referring IRC discussions.

http://wiki.openstreetmap.org/w/index.php?title=Namesdiff=nextoldid=976484

While IRC discussions may be good for intra-cultural things, it's better to
discuss such large topics on mailing lists, and at least not revert such
data silently.

-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Can wikidata links help fight name inflation?

[Komяpa]

 I'm genuinely curious: How do people in Russia search for places that are
 not in Russia? If you search for London, do you search for London or do you
 search for Лондон?
 I know I am not searching for Москва, Новосибирск, or Владивосток when I
 need Moscow, Novosibirsk or Wladiwostok. I can't even type those
 characters. Wouldn't it be normal that placenames are transliterated?


People in Russia usually use russian names of objects.

Culturally, until google maps was invented, every family in xUSSR seemed to
have ~300-page world atlas, (
https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%BB%D0%B0%D1%81_%D0%BC%D0%B8%D1%80%D0%B0),
that has all the names in the world in Russian.

Not everybody can even read latin, at all. :)


-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Can wikidata links help fight name inflation?

[Komяpa]

Hello,

I'd like to share my story.

We're making a new Global Map for World of Tanks game.
Game is translated into many languages, of which Russian and English are
most significant.
Now we're in open beta, you can look at the map at
https://ru.wargaming.net/globalmap/

To release the map, we need the whole map in Russian, and in English.

For closed beta, we chose to enable a small subset of a map, 80 provinces,
for which I manually added the translations:
http://www.openstreetmap.org/changeset/30451655

This changeset got reverted by SomeoneElse:
http://www.openstreetmap.org/changeset/30706979

Now we can't use OSM to render the map directly.

To go to Open Beta, as was suggested on IRC, we used automatic
transcription modules, and did _not_ change anything in OSM.
(if you think making automatical translation from not-known-for-sure
language to russian is easy, go try it! :)

Let's take a case:

http://www.openstreetmap.org/node/286131994 - Slough, GB. Pronounced /ˈslaʊ/,
which corresponds to russian Слау.
Wiki page http://en.wikipedia.org/wiki/Slough links to russian
https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D0%B0%D1%83.
That translation was added in 30451655 and deleted in 30706979.

Automatically translated province in Russian is called Слоф, not Слау:
https://ru.wargaming.net/globalmap/#province/slough
 - and we have no way to correct that, if we don't add name:ru for it to
OSM.

This is just one case, I bet we have a lot more that I just didn't have
time yet to investigate.

So, this is the story.

How do we cover this use case in OpenStreetMap, with its
eager-to-revert-names-in-languages-I-don't-speak users?


2015-05-28 0:13 GMT+03:00 Frederik Ramm frede...@remote.org:

 Hi,

we're seeing more and more name:xx tags on OSM objects.

 Not only are speakers of widely used languages adding their language
 tags all over the world; but rising interest in OSM also brings us to
 the attention of language lovers and speakers of minority languages. The
 less established a language is, the more committed its few proponents to
 have their language respected and recorded.

 The place node for London has 154 name tags as we speak, but there are
 several thousand languages in use on the planet, so there's still room
 for enhancement.

 Not only well-known tourist magnets carry foreign names; some dedicated
 language mappers have gone over and beyond the call of duty and added,
 for example, name:ru tags even to small villages:

  http://taginfo.openstreetmap.org/keys/name%3Aru#map

 (This is a matter currently under investigation by Data Working Group
 and it is relatively certain that not all 582,653 name:ru tags will
 remain.)

 It is difficult to judge when such foreign names have a right to be
 there, and when they're just inventions or name translations or
 transliterations. I guess we'll have to make rules on that somehow, but
 at the same time I dread doing it, and I wonder:

 If a place has a wikidata tag, could/should we then simply defer to
 Wikidata for names in other languages?

 We are a database of geodata and not one of international cultural
 heritage; even if London has a name in over 2000 languages, is OSM
 really the place to record these 2000 names? Would it not be better to
 record the wikidata link for London, and then (perhaps in co-operation
 with people at Wikidata) provide means for people doing map rendering to
 join OSM data with a separately-loaded translation table from Wikidata?

 We could then limit ourselves to using a name tag for the locally used
 name, or continue to allow a name:xx but only if these languages were
 actually used by the local population; throw in an int_name if you want
 (but some may say that's already an unfair privilege for users of
 English and the Latin alphabet). Anything else - i.e. names used for a
 place in other languages than the local ones - would be off-topic for
 OSM and should be recorded in Wikidata.

 Do you think Wikidata could play that role, and take the burden off of
 us? Or is Wikidata not mature enough for that yet, or even unsuitable?

 Bye
 Frederik

 --
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk




-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Can wikidata links help fight name inflation?

[Komяpa]

Hello,


 name:pronunciation, as mentioned on that page, is in use in a few
 problems, and would surely solve the Slough problem:

 http://www.openstreetmap.org/node/10021975/history

 (though John Betjeman's idea might have been better)


Would you please recommend a tool to transform name:pronunciation into
russian cyrillic name? (and, if possible, for other languages.)

In fact, what really needed is a tool (csv, database field, tag, bulk API,
whatever) that will quickly return a name of object in a given language,
even if it's absent in OSM data, integrated at least with osm2pgsql.

(generation of our russian-only map took a couple of days, and we had to
limit number of labels to finish it at all - keep in mind our map is
limited to z10).

Until then, people will keep adding name:xx to objects regardless of what
anybody thinks of it, as it's the only realistic way to render multilingual
map now.

-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)

[Komяpa]

 - is a database generated by osm2pgsql with an hstore expected to perform
 similarly to one without?

It performs at the same speed for me.

Of course you're not supposed to use hstore for every tag, but just
for those on highest zoom levels, where spatial indexes are used
mostly, not indexes for other columns.

-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenAerialMap geotiff compression

[Komяpa]

Hi,

Read and tried http://docs.oam.osgeo.org/storage/creating.html. It's
really nice to have 5 megs of geotiff instead of 700 :)

Serving tiffs with MapServer:
http://latlon.org/maxi?zoom=14lat=56.33918lon=30.5554layers=0FFFBT

Still, there are some things I would like to clear / discuss.

1) gdaladdo final.tif 2 4 8 16 32 64 128 256 makes not beautiful
overviews. If I add -r average, some artifacts start appearing, like
the vertical stripes on the link above. Any good ways to fix that?

2) why is EPSG:4326 used for saving images? Images look distorted in
it when they're not on equator. Isn't it better to use EPSG:3857
mercator, which is in fact used everywhere to display imagery and map
data?
Also, a far as I can see, jpeg compression has quantization matrix
that is kinda optimized for human eye, letting more higher frequences
horizontally than vertically. And after that we crop off another
portion of high frequency information on vertical axis.

3) JPEG compression artifacts.
Black field outside makes outmost blocks appear darker and be dirty:
http://latlon.org/maxi?zoom=18lat=56.32465lon=30.61984layers=0FFFBT
This can be avoided, as far as I can see, in two ways:
a) easier one, on compression, if we fill NODATA region inside these
blocks not with black, but with bilinear average of other data inside
block, there will be no black blocks.
b) harder one, make custom jpeg decompressor that will take exact
value for nodata region into account and try to restore values for
DATA region (not sure if it's really possible).

Same about compressing overviews. Probably nearblack can be patched to
fill regions not with black but with any kind of average, as
quick-and-dirty solution?

4) any beautiful programs to manage mosaics (chop off clouds,
selecting which image goes over which...) around? ;)

-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overpass API: new version 0.6.93, now with meta data

[Komяpa]

 [@newer=2011-08-01]
    restricts the data to only those data last edited after the given
    date. This is only possible in combination with another conditional.

Why wasn't something like [@timestamp2011-08-01] used?

-- 
Darafei Komяpa Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [OSM-dev] Kothic JS - a full-featured JavaScript map rendering engine using HTML5 Canvas

[Komяpa]

 It's much faster now, but yes, it was 5-8 minutes. Now it takes about
 16 seconds.

Is it still ~16 seconds, or is faster now? (There was a heavy load on
a server when
the whole thing was released, now applied some tweaks so it hopefully
will be accessible.)

-- 
Darafei Komяpa Praliaskouski
OSM BY Team
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Web browser mapping test

[Komяpa]

Hi,

If you've got a couple of free minutes, and you've got a good
eyesight, please take part in this thing. And don't forget to ask your
friends to check it too.

It will help others to develop cool browser-based maps, that won't put
lots of load onto server. But for that, we need fast and consistent
browsers behavior.

So, open your favorite browser (and a couple of others) on available
devices (PC, Mac, laptop, mobile device, different OSes..),
and point it to URL http://kothic.org/js/

Wait the page to load fully. Check:
[ ] the time it needs to be rendered - it should be below 2 seconds
typically for each tile on PC (Total ms - panel on the right), not
tens of seconds and of course not minutes;
[ ] the thin lines look good, have no random gaps and are anti-aliased well;
[ ] horizontal labels don't become blurry, and all glyphs are looking good;
[ ] fonts are anti-aliased according to your system's settings, and
don't have jumpy effect when are following paths;
[ ] transparent labels are transparent. Good to check with Минск
label in the center of your screen after page load - it should be
grey, not black;
[ ] there are no disappearing letters on labels that follow the streets curves;
[ ] bold fonts on streets are consistently bold, letters look the same
amount of bold with every angle. If unsure, recheck with
http://osmosnimki.ru/kothic/text-rotate.
[ ] something else that we haven't found yet?

Note: Labels can be different among different browsers - that's OK,
providing that they look good, have no gaps and so on.

If you've found any of these problems, please report that as issue to
your browser development team.

A CC/BCC or a link to a report (if applicable) to m...@komzpa.net would
be nice, too - I'll add reports to the list at Kothic JS's wiki.

There's a list of already reported bugs on Kothic JS's wiki - don't
hesitate to add your comments
(browser version, video card brand, OS, how you wish for it to be
fixed, ...) to the reports, and ping the developers about that
in IRC (or any other ways you know). Or, if you're able, fix them? ;)

https://github.com/kothic/kothic-js/wiki/Browser-bugs

Thanks for the attention. Let's make maps better! :3

If you think that you've found a bug in Kothic JS which is not
browser's bug, please report it to
https://github.com/kothic/kothic-js/issues


-- 
Darafei Komяpa Praliaskouski
OSM BY Team
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Kothic JS - a full-featured JavaScript map rendering engine using HTML5 Canvas

[Komяpa]

Hi all,

Glad to announce the first release of Kothic JS map rendering engine.

There's live demo on http://kothic.org/js/

Main features are:

 * Pure javascript - no closed-source proprietary components like
Silverlight or Flash;

 * Crossbrowser and cross-platform - works wherever you've got
JavaScript and Canvas;

 * Rendering quality is superb and is on par with server-side
renderers like Mapnik;

 * MapCSS support - reuse your stylesheet in other renderer, like
Mapnik (using komap preprocessor), Halcyon or JOSM.

 * BSD license.

GitHub repo: https://github.com/kothic/kothic-js (contributions welcome!)

Core contributors:
Darafei Praliaskouski (me=Komzpa, RDC ScanEx)
Vladimir Agafonkin (Mourner, CloudMade)
Maksim Gurtovenko (Miroff)

PS: June 10th, it's my birthday :3

-- 
Darafei Komяpa Praliaskouski
OSM BY Team
xmpp:me at komzpa.net mailto:me at komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Landsat WMS is dead

[Komяpa]

Hi,

2011/1/10 Stephan Knauss o...@stephans-server.de:
 On 10.01.2011 00:10, Vincent Pottier wrote:

 In JOSM I use
 Landsat (mirroir) wms:http://irs.gis-lab.info/?layers=landsat;

 that returnes totally blurred images when compared to the original ones.
Could you please give an example? I didn't find one when was setting
this up, and didn't use it since that moment.

Tried it now, and it works more-or-less for me.

 I thought it could be an issue with resizing the pictures before delivering.
That thing is trying to follow tiled wms spec when asking from NASA's service.
Unfortunately there's no useful spec around the web and was no real
way to check whether I got it correct or made mistakes, as incorrect
tiled request might be a correct non-tiled request and still return an
image.

 Even tried to contact the guys running it with out success.
Which one? If you're talking about me / irs.gis-lab.info, feel free to
ping me to m...@komzpa.net or on IRC.
If you're talking about landsat server admin, his e-mail was on
GetCapabilities of that WMS.


 As landsat was workign fine after a while I did not follow up on this. Looks
 like now it's a bit late, they shut the WMS down.
Landsat was never working fine. As their server admin noticed, the
whole thing was served from single P4-like machine that was dying from
WMS requests from all over the web.

-- 
Darafei Komяpa Praliaskouski
OSM BY Team
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Realtime satellite imagery access for OpenStreetMap granted - Russian Fires

[Komяpa]

Hi everybody,

Due to fires in Russia, ScanEx company have set up live updating
stream of satellite imagery from SPOT4 and Landsat satellites.

Now, they give OpenStreetMap users access to this stream.
What they want in return is mapping of burnt areas with
burnt=-MM-DD dates, taken from imagery metadata, probably with
addition of landuse=forest/field. You may also map any other things
you want from that imagery.

To access it, you should go to http://fires.kosmosnimki.ru/ (only
russian UI, unfortunately), select a satellite image you want to map,
click it and copy the JOSM WMS URL to your josm or click the Potlatch
link.

The press-release about that or whatever it is called:
http://blog.kosmosnimki.ru/2010/08/14/fires-openstreetmap/

A step-by-step instruction on how to map burnt places (in Russian, too):
http://blog.latlon.org/2010/08/13/kak-risovat-pozhary/
A rather ugly GTranslate translation of it: http://tinyurl.com/39o4v6d

Please spread it.

PS: Hope it won't drown in licensing talks, like previous landsat
announcement did.

-- 
Darafei Komяpa Praliaskouski
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Landsat?

[Komяpa]

Hi,

2010/7/30 Tomas Straupis tomasstrau...@gmail.com:
 Hello

  Is anybody else experiencing landsat problems in JOSM?
  For about three days now landsat images are not available to JOSM.
  http://onearth.jpl.nasa.gov/ says something about evil „repetitive
 requests for non-cached, small WMS tiles“. Does that mean no more
 landsat in JOSM?
Sorry for a slow reaction.

We've set up caching proxy for JPL's landsat at GIS-lab.
The URL for josm is:
http://irs.gis-lab.info/?layers=landsat;
For Potlatch 1.x:
http://irs.gis-lab.info/?layers=landsatrequest=GetTilez=!x=!y=!

I think it's worth updating your and _default_ josm Landsat entries to
use it, as it caches imagery and thus puts less load on OnEarth
server.

If you see fuzzy imagery in proxy, wait for half a minute and
re-request area - JPL's server is rather slow back-end. However,
migrating all josm users to gis-lab cache will let it breathe easier.

-- 
Komяpa aka Darafei Praliaskouski
xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Abnormal votings on military objects in RU wiki part; PocketGIS madness

[Komяpa]

Hi,

As was mentioned above, I'm not Russian citizen, I'm from Belarus,
which has a lot stricter laws sometimes.

This message represents my point of view, that may or may not be
supported by other members. Most of the quotes are approximate, since
initially they were badly grammatically constructed and can't be
directly translated to English. If I had totally misunderstod
something, feel free to correct me in this thread.

(I had to write this passage after reading some PocketGIS team
members' comments on forum like shame to do like this and
calling that initial letter a coward act and calling a third force to
the discussion. PocketGIS wasn't called a third force, talk@ was.)

About legality. There are readings of laws in forum thread that state
you can't give out a secret that you weren't told, and that a person
needs to sign a paper when they gain access to military secret data. I
think they won't publish it in OSM anyway.
Reference numbers of military areas are usually printed on enterance
gates, and usually can even be photographed.

Second, a bit about Wikimapia. Wikimapia: 1) is a project that is
hosted in Russia and by russian citizens 2) has a lot more military
features mapped, up to types of missles 3) there are no attempts to
prevent Wikimapia from doing that, neither legally nor by brute force.

A bit of background about PocketGIS. Right after Zkir published his
translarion of first Frederik's e-mail in a forum thread that was
calling everyone to vote delete all military features and do
everything allowed by law against people who add them, he was told
that his post will be deleted in case he doesn't provide the
translation for the whole thread in 24hrs, and that it shouldn't be
discussed in that pinned topic. (http://tinyurl.com/y6v8otc)

Forum thread on OSM froum also contains some interesting answers to
this maillist thread. If their respective authors won't post
themselves, I will translate and post those here.

-- 
Komяpa aka Darafei Praliaskouski
http://osm.komzpa.net xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Abnormal votings on military objects in RU wiki part; PocketGIS madness

[Komяpa]

Hi all,

Let me tell some news about what the hell is going on in russian OSM
community (wiki+forum).

First, there's some strange voting on wiki. http://tinyurl.com/y8etzgy
It's about mapping military objects. The strange tings are that it
didn't have proper RFC period, one of the things it proposes is
delete all the military fom OSM database, and that thing has ~50% of
votes. Strange votes, copypasting a large portion of text.

Also, there's a connected forum thread (http://tinyurl.com/yeee4rd,
50+ pages), that show some more details. First, there are different
readings of the law, if it is illegal to map such objects in OSM.
Second, those strange votes come from PocetGis users community (a
proprietary traffic-jam-aware software for WinCE, that uses OSM data),
which had a solidarity vote on the problem, when the lead developer
asked everyone please vote thsi way for our project to live.
(http://tinyurl.com/ycyqzp4). Also, they had an illustrated HOWTO on
registering and voting in OSM wiki. (http://tinyurl.com/y8hlwx8)

There are at least two changeset that remove landuse=military tag
from militery objects for now.
http://www.openstreetmap.org/browse/changeset/4282763
http://www.openstreetmap.org/browse/changeset/4282759
There will be more, if they will formally win.

Also, they (vctos, the lead developer) started some strange topics on
What is in OSM? Democracy or anarchy? Let here be our democracy. He
says that now the community is controlled by a number of hackers and
wants a voting on strict rules and positions, who will do what.
Seemingly, to be the key person in osm-ru (http://tinyurl.com/ya4tjcc)

If there's somebody who can stop that madness, please do it. Or at
least vote in that voting.

-- 
Komяpa aka Darafei Praliaskouski
http://osm.komzpa.net xmpp:m...@komzpa.net mailto:m...@komzpa.net

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk