Re: [OSM-dev] All possible fields of an address object in Open Street Map

[Martin Koppenhoefer]

Am Mo., 11. Mai 2020 um 16:33 Uhr schrieb Eugene Alvin Villar <
sea...@gmail.com>:

> I am sorry because my reply is not directly related to your questions, but
> please see the following article when considering building a worldwide
> address framework or database:
> https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
>
> This also means that addresses in OSM is very much inconsistent and
> incomplete both on the data side and on the tagging side.
>


it could become your task to make an addition to the address tagging scheme
if what we have so far isn't suitable for your area. It's how it is
evolving: people proposing additions to meet with their local requirements.

Cheers
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM Database schema

[Martin Koppenhoefer]

sent from a phone

> On 4. Jan 2020, at 17:28, Jean Marie Falisse  wrote:
> 
> Is it still true that in the OSM database, areas are not represented as such?


areas can be represented as areas through multipolygon relations which are 
always areas or by help of an additional tag (area=yes/no), or through 
plausibility (tags and their combinations may imply an area or not). There 
isn’t a dedicated area object, maybe this is what you meant. Areas are 
represented with ways, and tags or relations are required to define the ways as 
areas.


> That would mean, for instance, that a pedestrian zone, let’s say a big square 
> in a city, cannot be made to be crossed diagonally when used in a route 
> planner. Am I right?


typically routing engines operate on graphs, i.e. they do not route diagonally 
across areas, but this isn’t related to the question whether there is a 
dedicated datatype for areas or not.

Cheers Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] re-creating turn restriction geometry from osmosis based postgis

[Martin Koppenhoefer]

sent from a phone

> On 19. Nov 2019, at 17:03, maning sambale  wrote:
> 
> My db has the ways, nodes table with geometry and relations and
> relation_members referencing the members.


you could count all relations with type=restriction where the via member is in 
your polygon.

Cheers Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Processing dual carriageway highways into one linestring?`

[Martin Koppenhoefer]

You would also have to know how many ways there are, just looking for 2 is
not sufficient, because there could be 3, 4, 5, 6 or even more. Around here
I've a situation with 6 parallel carriageways:
https://www.openstreetmap.org/#map=19/41.86472/12.49702
some meters north of this spot, they are even 7 for a short length (or 8,
if you count the cycleway and 9 if you also count the parking aisle).

And you would have to decide when not to do it, for example Via Palos runs
for some time parallely but then makes a turn and passes under the bridge:
https://www.openstreetmap.org/way/257174994#map=17/41.86821/12.49583

And if there are ways that run along the "principal" highway for some time
at only one side, but then vanish, and you calculate the center for the
"synthesis", it will put corners or curves in your main way which actually
runs straight.

You will surely have to define a maximum distance threshold for this
unification, and you always will have edge cases around this threshold
which can cause inconsistency.

Depending on your purpose, you also may want to not unify parallel ways
when they run on different levels, e.g. one on a bridge or embankment (e.g.
along a retaining wall), or in a cutting.

As you probably know, the typical OSM solution for this is raster
rendering, because then the ways merge visually and "automatically" (as
their width is usually exagerated and layer ordering renders first the
casing then the fill).


Cheers
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Use of OSM API for non-editing third party applications

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2019, at 16:21, Jóhannes Birgir Jensson  wrote:
> 
> I never read anything where it said that OSM-auth was only for editing. So I 
> have worked on the assumption that the answer would be yes, you can piggyback.


it’s written here:
https://wiki.openstreetmap.org/wiki/API#Terms_of_use


Cheers Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] 403 forbidden

[Martin Koppenhoefer]

sent from a phone

> On 31. May 2019, at 08:08, Vijaya Nand  wrote:
> 
> Please suggest me how I can check what's wrong with gmap.net


it was already written, the reason is they are faking the user agent and are 
not willing to change this 


Cheers, Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Fwd: Request for a Map as JPEG export

[Martin Koppenhoefer]

sent from a phone

> On 16. Apr 2019, at 10:18, Frederik Ramm  wrote:
> 
> Method 3:
> 
> Another option might be to use only QGIS, and start by adding an OSM
> layer from a free WMS server https://wiki.openstreetmap.org/wiki/WMS and
> then add your KMZ on top. The "print composer" in QGIS should then allow
> you to create a large image. The output quality of this approach depends
> on whether or not the WMS supports high(er) resolution output; worst
> case, it will be only screenshot quality.


I would also recommend QGIS if you need a specific image. The mapnik rendering 
approach is worth the extra hassle only if you need to repeat the thing many 
times. You can import an extract in a Postgis db with osm2pgsql and make 
queries through QGis, it is still some work because you have to style the 
elements you want, and you should know the OpenStreetMap tags for the queries, 
but you do not need a lot of different features for a simple basemap, and can 
add all kinds of sources from a GUI.

Cheers, Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Export broken?

[Martin Koppenhoefer]

Hi John,

You requested too many nodes (limit is 5). Either request a smaller area, 
or use planet.osm

Cheers, Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM augmented reality project - affordable hosting recommendations or Overpass?

[Martin Koppenhoefer]

e.g Hetzner, for 30 bucks you can get 48 gb of ram and 2x2tb disks on a root 
server
https://www.hetzner.com/sb

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

Re: [OSM-dev] renderd queue

[Martin Koppenhoefer]

Am Do., 20. Dez. 2018 um 19:20 Uhr schrieb Kojo :

> Hi all,
>
> How do I check the renderd queue?
>
> I am having a huge database load, even if there are no incoming requests
> for not rendered tiles.
> I presume that there is a queue in process using my database (Postgres]
>  resources. Is it correct?
>


maybe autovacuum? It is enabled by default.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] iD news - 2.12.0 released 🎉

[Martin Koppenhoefer]

Am Mo., 10. Dez. 2018 um 13:51 Uhr schrieb Andrew Harvey <
andrew.harv...@gmail.com>:

> If you search for a preset with a brand, eg. McDonalds and select that
> it will populate:
>
> amenity=fast_food
> cuisine=burger
> name=McDonald's
> brand=McDonalds
> brand:wikidata=Q38076
> brand:wikipedia=en:McDonald's
>
> Then the name field is locked from editing in your session so you
> can't change it, unless you go down to the advanced "All tags" section
> where you can edit any of these locked free form tags.




I would find it strange if a brand:wikidata tag locked the "name" tag,
brand is mainly used for "grouping" of multiple instances (it somehow
defines a category/common property), while name is an individual tag for
instances.
Looking up your McD example with overpass turbo, I found 572 objects with
brand=McDonald's and a name different to "McDonald's", out of 841 total
objects according to taginfo.

I like the idea though to connect brand and brand:wikidata, and require an
extra click (or going to "all tags") when your edit makes them inconsistent.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Question Answering over OSM and searching by tags

[Martin Koppenhoefer]

sent from a phone

> On 29. Oct 2018, at 14:06, Dennis Diefenbach 
>  wrote:
> 
> So an end-user cannot simply search for “tram stops in rome”. The only way is 
> to construct a formal query like:
> 
> node
>   [amenity=tram_stop]
>   ({{bbox}});
> out;
> 
> which is not trivial.


overpass Turbo has a wizard which creates queries from search phrases.


Cheers, Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] New OSM Data Export: Deleted User Account IDs

[Martin Koppenhoefer]

In this context it would be interesting to get an idea how many people
asked themselves for deleting their own account. Does the list contain a
reason for the account deletion?

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [OSM-talk] anonymous notes spam?

[Martin Koppenhoefer]

sent from a phone

> On 20. Jul 2018, at 18:27, Andrew Hain  wrote:
> 
> Can we find out what software is being used to send these notes?


did you try to put the letters in chronological order? Maybe it is a hidden 
message ;-)

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Coastline – osm2pgsql

[Martin Koppenhoefer]

2018-06-21 0:05 GMT+02:00 Sven Geggus :

>
> The coastline processing toolchain is available here:
> https://github.com/osmcode/osmcoastline



you can also get precompiled (fixed, splitted and not, 4326 and 900913)
water polygons, land polygons and coastline shapefiles here:
http://openstreetmapdata.com/

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] GDPR implementation on planet.osm.org

[Martin Koppenhoefer]

2018-06-20 9:26 GMT+02:00 Simon Poole :

>  There are still some open questions on
> exactly what needs to be done, in particular wrt transfers of data to
> countries where the EU hasn't made an equivalence determination, but we
> are slowly firming that up.
>



For reference, the countries that have been determined equivalent are these
(plus the EEA countries):

The European Commission has so far recognised Andorra, Argentina, Canada
(commercial organisations), Faroe Islands, Guernsey, Israel, Isle of Man,
Jersey, New Zealand, Switzerland, Uruguay and the US (limited to the Privacy
Shield framework
)
as providing adequate protection.

Adequacy talks are ongoing with Japan and South Korea.
Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Martin Koppenhoefer]

2018-04-16 18:34 GMT+02:00 Marco Boeringa :

>
> No, buildings are not the most interesting. I once generalized all
> buildings in Denmark. It only reduced the storage by maybe 5%, at the high
> cost of heavily distorting a large number of them. Most buildings in OSM
> are in fact already in their most generalized state: just 4 nodes. Unless
> you think triangles is a suitable representation ;-).
>


it really depends on the zoom levels (=detail you want) and building
structure. If there is a closed building block there may be a lot of those
4-node-houses which all together could be generalized to one 4 node block.
If there are scattered houses in a rural setting, you still can omit the
smaller ones or make one bigger structure by combining several smaller
ones. Many buildings also do have more than 4 nodes.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Martin Koppenhoefer]

2018-04-16 10:34 GMT+02:00 Martin Koppenhoefer :

> still AFAIK, 1 and 3 are currently still from natural earth data, the rest
> is from OSM, 2 is a simplfied version of 4, both come from
> openstreetmapdata.org (Christoph and Jochen). Of these, 1-3 are
> containing generalized data.
>


according to Paul Norman in the video recording, also 5 and 6 are
generalized.
Another aspect is filtering: osm-carto removes features when they would be
very small (pixels at a given zoom level) and lead to "noise".

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Generalisation

[Martin Koppenhoefer]

AFAIK, in the osm-carto style there is no generalization on live data for
performance reasons (because of continuous data updates via minutely
diffs). There are some precomputed / extracted data files though, some of
which contain generalized (simplified) data. These are all "external"
sources:




   1. world_bnd_m.shp, places.shp, world_boundaries_m.shp
   

   2. simplified_land_polygons.shp
   

   (updated daily)
   3. ne_110m_admin_0_boundary_lines_land.shp
   

   4. land_polygons.shp
   
   (updated daily)
   5. icesheet_polygons.shp
   
   6. icesheet_outlines.shp
   





still AFAIK, 1 and 3 are currently still from natural earth data, the rest
is from OSM, 2 is a simplfied version of 4, both come from
openstreetmapdata.org (Christoph and Jochen). Of these, 1-3 are containing
generalized data.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Working with OSM data with less or no metadata

[Martin Koppenhoefer]

2018-02-16 13:37 GMT+01:00 Simon Poole :

> The intellectual property rights (I re-quote: "that is restricted by
> copyright, database right or any related right") have nothing to do with
> the subject at hand, the data privacy rights of the individual data
> subject. As a consequence the contributor terms have no bearing, in any
> form, at all, even in an alternative universe, on the matter.
>


I really have no idea what "related right" means, not even if it relates to
"copyright and database right" or to "Contents".




>
> If you look at our recommendation document you will note that we believe
> that we currently do not have consent as defined by the GDPR for the
> processing we do. As a consequence we will likely recommend  asking for
> explicit consent somewhere in the sign up process (from a content pov this
> already exists in the privacy policy but it needs to be re-jigged to work
> as part of the terms of use that will have to be explicitly agreed to for
> account creation).
>
> However having valid consent for current processing does not remove the
> issue that Paul has pointed out (again) that consent can be redrawn and
> that such a withdrawal applies retroactively. The main cause why we one way
> or the other should change what data we distribute to the general public.
>


by asking explicitly we would confirm we believe that privacy rights are
relevant, and it could indeed become more of a problem as people revoke.

You are refering to this document:
https://docs.google.com/document/d/1EjccQNm3awl7eQlk1jGYyoGJVavJG_bEfX8iCMEuC9U/edit#

The relevant paragraph is "Does the OSMF process ‘personal data’?"

I don't share the interpretation that OSMF processes personal data (besides
the e-mail addresses and maybe IP addresses used by its contributors, which
are neither distributed nor public), because I don't think that our mappers
can be identified with the data and metadata of their contributions. I.E.
they are not identifiable natural persons because they cannot be
identified, directly or indirectly. Yes, if you know who they are you can
see what they did, but you cannot see from what they did who they are. At
best you can guess, but it only works if you have additional information
that the person (or someone else) would have to provide you with. What we
have according to these definitions is "pseudonymisation" (because OSMF has
the sign-up e-mail address associated with the user number, and is therefor
in a position to make personal data from the contributions).

If someone tries to reverse the pseudonymisation of our contributor's data
and metadata, it would be this person to be in breach of the law.

An exception might occur in very rare cases in areas where the contributor
is the only person being there within a big distance, i.e. extremely remote
areas, and probably not in the European Union.

For reference,

General Data Protection Regulation
https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_en


Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Working with OSM data with less or no metadata

[Martin Koppenhoefer]

2018-02-16 0:04 GMT+01:00 Paul Norman :

> On 2/14/2018 8:17 AM, Roland Olbricht wrote:
>
>>
>> - How about simply asking the users for consent? We could then
>> -- make a clear-cut last complete history dump before the date
>> -- start with a planet dump without history before that date afterwards
>> that then accumulates history only from users that have given consent
>>
>
> Consent is revocable. If we didn't have to deal with people revoking
> consent and account deletion requests, it would all be much easier.




We are asking for "a worldwide, royalty-free, non-exclusive, perpetual,
irrevocable licence to do any act that is restricted by copyright, database
right or any related right over anything within the Contents, whether in
the original medium or any other." Do you have reason to believe the
"irrevocable" part is invalid?

"Contents" means "data and/or any other content (collectively, “Contents”)"
[which the user contributes] "to the geo-database of the OpenStreetMap
project"
https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms

Account deletions are another issue, but don't seem complicated: remove the
human readable account alias and e-mail forwarding and prevent it from
editing.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Working with OSM data with less or no metadata

[Martin Koppenhoefer]

2018-02-14 17:49 GMT+01:00 Simon Poole :

> Generally I would prefer if we could simply have two versions of
> everything, one with metadata for authenticated users/consumers one
> without.
>


+1. This sounds like sane measures, the metadata is really an important
part for the community to work with the map.

I believe it is an overreaction to speculate about privacy issues with osm
metadata, which is pseudonymous data. You cannot deanonimize it without
other, additional data (e.g. real name, address, ideally combined with the
same nickname elsewhere, habits, interests, etc.). Yes, you can find the
center of activity of an active mapper, in some cases even the interests,
but that doesn't mean you can tell the residence or identity (save maybe
very few situations of people living in very low density areas). There also
isn't a very direct correlation of your edit and you being at a place (IP
addresses shouldn't be released of course), you can (and many do) add
something weeks, months or even years after you have observed it, you might
have used aerial imagery, or internet research, or mapillary, or edited for
a friend...

If it is required nonetheless, I'm with Roland, we should ask for explicit
permission.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Working with OSM data with less or no metadata

[Martin Koppenhoefer]

2018-02-14 10:30 GMT+01:00 Michael Reichert :

> Hi,
>
> people are talking about potential changes to the amount of (personal)
> data distributed by OSM, in the light of new data protection laws
> becoming effective in the EU this May.



it seems Brexit could become effective March next year. Maybe we just wait?
What is the UK position regarding the planned EU data protection amendments?



> All challenges are run four times, one iteration with full metadata, one
> with timestamp and version fields, one with version field only and one
> without any metadata.



if you consider timestamps and version fields private data, you could also
consider object ids private data (they are assigned consecutively, you
could create delete frequently "test" objects to correlate object ids and
timestamps ;-) ).

I really hope we will not obfuscate or remove meta data because of some EU
privacy regulation, please do not overreact.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Scale of downloaded images seems to vary.

[Martin Koppenhoefer]

2018-01-11 12:06 GMT+01:00 Bjoern Hassler :

> Hi Tom, dear friends,
>
> I'm not really sure what you mean by geographical scale?
>
>
> It would be helpful to have text like this:
>
> "This image is 90.7 dpi, or 28 dots per cm.
> If printed at this dpi, the scale will be 1cm to 25,000 cm."
>


note that this will always only be approximate as it will vary across your
sheet of paper (getting smaller towards the equator and bigger towards the
poles in the mercator projection we use), so you would want to say
something like "the scale in the centre of your sheet will be 1 : 25000")

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Automatically triggering export as PDF from openstreetmap.org -> share?

[Martin Koppenhoefer]

2017-12-22 10:27 GMT+01:00 joost schouppe :

>
> Third, you should be able to rotate through the set of places with the
> Atlas function.
> Last, export to PDF; I have no idea if QGIS can produce the kind of PDFs
> you need.
>


I've also recently made some maps for print with QGIS. As Joost says, you
will usually get a pbf osm file, import it into a database (I'm using the
standard osm2pgsql with latlong for this with hstore, although my QGIS
versions requires to create views for selecting hstore fields, which makes
it a bit more tedious, in the end I got it working). I'm using latlong
because I'm reprojecting on the fly to different systems in different
areas.

QGIS lets you export / print to raster (png), pdf (AFAIK both, raster and
vector, there's an option "print as raster") and svg (not working well,
e.g. I had problems with uncropped lines at the border). Depending on your
settings (resolution, scale and feature density on the map), it is not a
given that a vector representation will produce smaller files in any case
(when zoomed in you will usually get smaller files, if there is a lot of
detail in a large scale map, you will not see it in the print, but it will
inflate your file).

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Getting POI nodes deleted by user

[Martin Koppenhoefer]

sent from a phone

> On 12. Dec 2017, at 01:11, Michał Brzozowski  wrote:
> 
> How can I, having a full history dump for an area, find all POI nodes (having 
> shop/amenity/office...) that were deleted by user rowers2?
> 
> Or, which DB schema can deal with history reasonably?


with osmium tool you might be able to do it in the shell with osmium cat in opl 
format and some cut and grep (if you can live with some false positives that 
later were undeleted)

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Andy Allan joining web site maintainers

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2017, at 11:48, Frederik Ramm  wrote:
> 
> It could be a low-hanging fruit
> to create feature parity between website and API at least in some areas.


+1, few people know you can request specific versions like the previous one, 
with big objects often running in timeout for the full history it would be 
convenient to offer a link to the previous version rather than the full history 
or after a timeout occurred.

Cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] looking for some spline code to adapt

[Martin Koppenhoefer]

sent from a phone

> On 2. Jul 2017, at 15:15, Christoph Hormann  wrote:
> 
> The problem is that in OSM we do not record any supplemental information 
> on ways regarding if the corners at the nodes are actual corners or if 
> they are just approximations for a smooth form of some sort - what you 
> would usually do with a kind of tension parameter.


at least we don't do it on a bigger scale, there are very few examples where 
someone has done it: https://taginfo.openstreetmap.org/keys/bezier

or has proposed to do it:
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Curvature

Maybe we should push for a common solution to add this kind of information?

Cheers,
Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Moving tags in JOSM

[Martin Koppenhoefer]

2017-06-08 11:45 GMT+02:00 Bjoern Hassler :

> (2) Is there a way of copying/moving tags from a node or way to a relation?
> Ideally something like "move tags to relation" -> "select tags to move" ->
> "select relation to move to (if more than one)" -> move. I am sometimes
> moving wikidata/wikipedia tags from nodes/ways to relations, and there
> doesn't seem to be a simpler way than manually copying them one by one.
>


you can copy tags from a way to a relation by first selecting the way and
copy it, then selecting the relation (e.g. by right clicking on the
relation name in the tags window, or by selecting it from the relations
window) and pasting tags (IIRR it's shift+ctrl+v), but it will overwrite
values of existing keys. You can also paste tags in the relation editor
(without needing to select the relation itself), first row of icons, "paste
tags". Both methods will overwrite existing tags AFAIR.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Printing to PDF

[Martin Koppenhoefer]

2017-05-27 0:21 GMT+02:00 Hartmut Holzgraefe :

> for standalone you may want to give https://github.com/Zverik/Nik4 a try
>


+1, thing is it requires at least half a day to set this up (database,
mapnik, download + import data) and get it all running, especially if you
haven't done it before. There are lots of potential problems involved and
the stack might be currently broken on your OS (at least this is what I
experienced on OSX with homebrew, where python bindings (required for nik4)
are available only for mapnik 2.2. but it doesn't compile)).

if you're on windows you can use mapertive, on Ubuntu I guess mapnik will
install easier, but with MapOSMatic (using a working deployment on someone
else's system) you could have a print in a few minutes, or similar with the
bigmap script (in screen resolution).
http://openstreetmap.gryph.de/bigmap.html

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Printing to PDF

[Martin Koppenhoefer]

sent from a phone

> On 26. May 2017, at 20:57, Bjoern Hassler  wrote:
> 
> I'd like to print a 30km by 20km area to a single A1 or A2 sheet. This is a 
> "sparse" area in Zambia, so downloading OSM data and rendering is quite 
> possible, rather than attempting to print tiles.



it depends what you want to do with the print, if it has to be pretty you 
should render in a print resolution (ask someone who has everything set up or 
setup a rendering stack yourself, otherwise you could print the tiles (if you 
need a big field paper to scribble on), e.g. with the bigmap.cgi script print 
to A1 pdf from the browser.


cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Wikipedia Matching

[Martin Koppenhoefer]

2017-05-19 13:23 GMT+02:00 Andy Townsend :

> I'd certainly take some of those added tags with a pinch of salt.  A
> number "place" objects near me have been linked to wikidata items by a
> well-meaning wikipedian, but unfortunately they don't actually match.  What
> tends to happen is something like:
>
> o OSM has a place object for a village and an admin entity
>
> o An OSM user adds a wikipedia tag to the admin entity.  The wikipedia
> entry describes itself as covering both the village and the admin entity,
> so that's OK.
>
> o A wikipedian writes a bot that creates a wikidata item from the
> wikipedia article.  The bot creates wikidata entries for villages, not
> admin entities.  That's not entirely wrong, because the wikipedia article
> actually covers both.
>
> o A different wikipedian spots that there is an OSM admin entity and a
> wikidata item with the same name in a similar location and links them via a
> wikidata tag.  This results in the wrong OSM entity being linked to a
> wikidata item.
>


+1, this is an example for a general issue with wikipedia, mostly their
articles cover both, the socio-geographic place and the administrative
entity, with parts of the data (e.g. population) usually referring to
administrative territorial entities. Wikidata has generally an item for
every article of Wikipedia, but not much beyond wikipedia articles, so even
if they state they are about an administrative territorial entity, often
they are also about the place, so linking it to OSM objects is kind of
problematic because there is some overlap in what is represented, but it is
not the "same thing" that is described.

It is not a huge problem to have slightly different wikidata/WP objects
(but with significant overlap) linked to OSM via tags, but people should be
aware that the linked wikidata object is not the same as the osm object,
but really is just a (hopefully) useful link to something somehow related.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Legal question about attribution text on smartphone

[Martin Koppenhoefer]

sent from a phone

> On 23. Apr 2017, at 00:26, Stadin, Benjamin 
>  wrote:
> 
> (UIActionSheet on iOS)


As a side note UIActionSheet is deprecated since iOS8 (2014)

Cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Legal question about attribution text on smartphone

[Martin Koppenhoefer]

sent from a phone

> On 21. Apr 2017, at 12:10, Rory McCann  wrote:
> 
> So I dunno? Maybe? There could be ways around it if you don't want to include 
> it on every map page. Does your app have a loading/spash screen? Including an 
> attribution there, which is shown every time the app is started might meet 
> the requirements.


have you seen this page?
https://wiki.openstreetmap.org/wiki/Legal_FAQ

generally, if there is enough space for your logo, there should also be for osm 
(on pages showing maps). If there's space for just one attribution, why not use 
it to attribute osm? The user will more likely be aware who you are (as he's 
using your app) than he will be that your map data comes from osm, so 
prioritizing OSM attribution seems to make sense 


cheers,
Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Regarding Where to Start using openstreet map

[Martin Koppenhoefer]

sent from a phone

> On 2 Apr 2017, at 13:10, Fleetfox GPS TRACKER  wrote:
> 
> Can you please suggest where to start


have a look at https://switch2osm.org/

cheers,
Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Programatic reconstruction of postal code areas

[Martin Koppenhoefer]

2017-03-29 12:14 GMT+02:00 Colin Smale :

> There are also in some countries "non-geographic postal codes" - things
> like reply numbers and PO Boxes.



they are geographic as well, just that their place is at the post box and
not at the owner of that box... ;-)

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Martin Koppenhoefer]

2017-02-24 13:11 GMT+01:00 Michael Zangl <
openstreet...@michael.fam-zangl.net>:

> This is a not a dev playground, this is a website that
> should be used by millions of normal users. It should provide an entry
> point for people that want to improve the OSM database. It should not be
> a maintenance tool.
>


which page do you suggest should those millions of users use after they
have become contributors and want to see tile urls?

It would be nice to have a custom right click menu, either completely
custom by user pref or for the start generalized in basic groups (like
logged in and not, where not logged in users get more "common map
right-click features", and logged in user get more mapper-interest right
click functionality). Current state could be used as default.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Turning boundaries to linestrings

[Martin Koppenhoefer]

2016-12-13 13:33 GMT+01:00 Christoph Hormann :

> On admin_level 2 a better way
> would be to classify this based on topology - i.e. all boundaries that
> are only part of one admin_level 2 relation are maritime boundaries.
>


that's a nice hack which will generally work, but having overlapping
boundaries (different ways on the same position) is not a clear "error" in
OSM, so it is not 100% reliable.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] planet.openstreetmap.org/replication policy

[Martin Koppenhoefer]

2016-11-28 14:33 GMT+01:00 Oliver Tonnhofer :

> It would also not reduce the bandwidth by much, as it still needs to
> download the same data.



it surely will use a lot fewer connections, but also the amount of data to
download can be significantly smaller, depending how often the same objects
get touched within the same day.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] A PostgreSQL extension for real-time simplification of objects in OSM API database

[Martin Koppenhoefer]

2016-11-17 11:08 GMT+01:00 Rory McCann :

> But... isn't there a danger that the mapper will load this
> simplified/reduced object in JOSM (etc), change the tags, then press
> upload? And then upload the simplified/reduced geometry? Which will make
> the OSM data worse?
>


there would have to be precautions, the editors supporting reduced data
download would have to take care that only unreduced data can be edited and
uploaded. Maybe the API-server restituting different ids for reduced data
could help here as well, so even if the data consumer / editor doesn't
implement a special rule and someone tried to upload simplefied data it
would not overwrite the un-simplified OSM elements or could be rejected.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Multipolygon relation way member without role

[Martin Koppenhoefer]

2016-09-19 5:50 GMT+02:00 patrick keshishian :

> Question: Is there a general rule used when processing role=""?
>


it depends on the type of relation



> OSM wiki for Relation [3] indicates that roles are optional.
>


yes, they are generally optional, save for certain relation types. A
relation is a very generic concept, and can be used for expressing a lot of
different things, For multipoligon relations, a role should be set (but
many tools, e.g. osm2pgsql) ignore them AFAIK.
http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Members

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] user closing lots of notes / howto revert?

[Martin Koppenhoefer]

Is there a way to bulk-download or even better bulk-reopen the notes a user
has closed? Recently a new user has closed 204 notes all over the place and
without commenting and replying "fgdjfjdks" to mappers contacting him, so
he was blocked by DWG.

The wiki suggests
http://wiki.openstreetmap.org/wiki/Notes#Viewing_notes_by_user
this URL: www.openstreetmap.org/user/xyz/notes
but this will split the results into pages of 10 (i.e. in this case 21
pages). Is there a way to raise this limit or maybe even download all of
them in one go?

Once you got the note IDs, which URL / API call will reopen it?

Thank you,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Tag-info: Tag descriptons

[Martin Koppenhoefer]

sent from a phone

> Il giorno 13 set 2016, alle ore 18:38, Dave F  
> ha scritto:
> 
> place=farm - a place named by a name of a farm
> 
> This appears to contradict the other (incorrect) description.
> 
> I'll discuss further on Talk forum


+1, actually tagging would seem most suitable 


cheers,
Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Planet change tile expiry list service

[Martin Koppenhoefer]

sent from a phone

> Il giorno 01 set 2016, alle ore 11:25, Andy Allan  ha 
> scritto:
> 
> It's not really something that should be relied on, since there's no
> "one true list" of expired tiles.


it also depends on the features you are showing in your rendering and at which 
zoom levels.


cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Polygon inner/outer relation in osm file

[Martin Koppenhoefer]

sent from a phone

> Il giorno 23 ago 2016, alle ore 15:21, Frederik Ramm  ha 
> scritto:
> 
> they can have missing or wrong inner/outer tags
> (usually considered valid)... the C++/Python library "osmium" is
> probably the most advanced in building proper polygons, or check out
> osm2pgsql, imposm, or ogr2ogr which also have code to deal with that.


recently we stumbled upon problematic behavior of current multipoligon 
processing in osm-carto, as it drops tags on inner relation members if the 
outer members (or the relation?) has the same tags. I believe this kind of 
"fix" should not be performed, it leads to problems if this kind of mapping was 
done on purpose, e.g. because of some properties being different.

Not applying "magic guesswork" also leads to more predictable behavior and 
ultimately to mappers fixing the representation in case it was wrong.


cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Modeling OSM sidewalk data

[Martin Koppenhoefer]

sent from a phone

> Il giorno 12 lug 2016, alle ore 11:15, Komяpa  ha scritto:
> 
> Both ways are only applicable to cities with blocky structure.
> In ex-USSR, architecture of cities is different, and footways / sidewalks 
> graph is more complicated than a replica of roads for cars, so all the 
> sidewalks have to be drawn separately.


There are sidewalks (alongside roads) and other footpaths, just like everywhere 
else (but in different proportions). You can decide to draw the sidewalks 
separately or not (like anywhere else), while you have in any case to draw the 
independent footways with their own geometry.

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Simple app for "making contributions" (not to display maps)

[Martin Koppenhoefer]

sent from a phone

> Il giorno 29 giu 2016, alle ore 14:04, Bjoern Hassler  
> ha scritto:
> 
> Is there interest in (or is anybody working on) creating an very 
> simple-to-use app that allows "non-technical" users to contribute OSM 
> information?


there are some simple apps available, e.g. Pushpin or maps.me (there are lots 
more of them, http://wiki.openstreetmap.org/wiki/Editors )
Generally editors that don't allow to change the geometry are simpler, but 
don't allow to perform certain corrections or additions.

While it is true that editing is never completely simple, a fair share of this 
is due to the complexity involved. There are some  people that can't read a 
map,  just because they have a smartphone now does not mean they can draw one.

I think a good way to make it simple is to reduce the scope. A dedicated app 
for (e.g.) petrol stations can ask the right questions and offer only those 
tags that are relevant. The more versatile the app gets, the more you will have 
to look for the gas station in the presets, and the more steps you'll have to 
go through.

Also every tag should be explained during insertion, e.g. that descriptions 
shouldn't go into name...

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] carto 0.16.0 released

[Martin Koppenhoefer]

sent from a phone

> Il giorno 15 apr 2016, alle ore 09:24, Oleksiy Muzalyev 
>  ha scritto:
> 
> RADIO/TELEVISION 2. a tall metal pole used to support an AERIAL for radio or 
> television signals: a television/radio mast
> 
> for the word "tower" meaning No.2
> a tall, usually metal structure used for broadcasting: a radio/transmission 
> tower.


do you notice that the mast version writes about a "pole"?


> 
> Google search of "radio mast", "radio tower", "television mast", "television 
> tower", etc. gives each millions of results with similar images. It seems 
> that the words "mast" and "tower" are interchangeable.


-1, there might be edge cases that can be described with both words, but many 
can not.



> The article in English Wikipedia is called: "Radio masts and towers": 
> https://en.wikipedia.org/wiki/Radio_masts_and_towers


and if someone writes an article about "life and death" that's both the same 
state? This article puts both types in one article because it doesn't care 
about the shape but about the function (radio transmission)


cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] carto 0.16.0 released

[Martin Koppenhoefer]

sent from a phone

> Il giorno 15 apr 2016, alle ore 08:01, Oleksiy Muzalyev 
>  ha scritto:
> 
> I started to re-tag communication towers, which I know, as 
> (man_made=mast;tower:type=communication). For example, this tower of 220 
> meters in the city of Mykolaiv is already shown on the map: 
> http://osm.org/go/0izbJWLIA-?m= , and before yesterday it was a blank spot.


IMHO you should not do this, man_made=mast with the meaning that is documented 
in the wiki is a poor tag, ill defined with a definition that contradicts 
itself and that doesn't reflect the meaning of the word, and which got sneaked 
into the wiki, but never was approved or positively discussed.

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Playback of Camera Movement in OSM2World Question

[Martin Koppenhoefer]

sent from a phone

> Am 19.03.2016 um 10:43 schrieb Oleksiy Muzalyev :
> 
> Here are the aerial images of Collège Madame de Staël in Geneva which I made 
> with the DJI Phatom 3 this week:
> 
> https://fr.m.wikipedia.org/wiki/Coll%C3%A8ge_Madame_de_Sta%C3%ABl#
> 
> https://commons.m.wikimedia.org/wiki/User:Alexey_M./gallery
> 
> An advantage of Wikipedia is that it keeps the original images resolution, so 
> building:levels are well visible. Google Maps automatically reduces 
> resolution.
> 


thanks for sharing, imagery of this kind is indeed perfect to determine 
building levels or also to get textures.


cheers,
Martin ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] WG: Merkaartor creates invalid highway tags like highway=unclassified; track

[Martin Koppenhoefer]

2016-03-15 10:55 GMT+01:00 Andy Townsend :

> However, this is still all a bit of a red herring



also exactly this kind of problem has helped me once in the past to
identify osm derived data on an incompletely attributed commercial map, as
there was an involuntary easter egg name (name=foo;bar;foo) that served as
a very strong indication of the data provenience.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Merkaartor creates invalid highway tags like highway=unclassified; track

[Martin Koppenhoefer]

sent from a phone

> Am 14.03.2016 um 23:57 schrieb Andy Townsend :
> 
> Now that you've "fixed" the data there there's no longer something that's 
> "obviously invalid" that people can see and say "I wonder what that is 
> supposed to be" before going out and surveying it.


this is a very valid consideration. I also quite often encounter people 
"fixing" situations they don't know by introducing then hard to spot errors 
because the tags are formally correct but don't fit the situation. Heretical 
question: Maybe we should exclude tagging all together from the QA tools? 
Basically this kind of tampering  makes the "cloud-fueled" development of new 
tags almost impossible, because mappers retag stuff to other tags that are 
already established even if they don't fit well.

This kind of cleaning worker also are typically very convinced of their work, 
so discussions with them tend to take a lot of time and energy, often without 
satisfying outcome (=auto reflection).

I feel we should put even more emphasis on people having been to a place, maybe 
asking mappers to refrain completely from contributing to places where they 
haven't been.

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Merkaartor creates invalid highway tags like highway=unclassified; track

[Martin Koppenhoefer]

2016-03-14 9:58 GMT+01:00 Gerd Petermann :

> I hoped that this problem was solved whe iD was corrected, but
>
> some less often used editors still allow to create these erroneous tags.
>
> Since iD was corrected the only changesets with these errors are created
>
> by Merkaartor  and Potlatch 2. Fortunately these editors are rather rarely
> used.
>
> I hope the programmers of these editors are also working on a fix ?
>



On a side note JOSM allows to create these tags, but it doesn't do it
automatically (if you merge/combine objects with different values you can
choose either one, none or all of the values and if you choose "all" they
get appended).

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] changes in coastline are not rendered

[Martin Koppenhoefer]

2016-02-11 8:11 GMT+01:00 Stephan Knauss :

> This is the reason I suggest against using the simplify functionality.
> Just because some detail level is not to your liking you sort of "tell off"
> those mappers who invested a lot of time putting that details in the first
> place when deleting it.
>
> There are special situations where it can be useful, but in case of
> "hand-drawn" data mostly it is fine to go forward with a handful of
> additional nodes. And don't worry about the size of the data. Those few
> nodes don't do much harm (we have 4 billions already).
>


+1, for the detail I suggest to keep whatever is hand drawn and is a
noticable improvement. To expand on this: If a piece of road is straight,
you shouldn't have more than one node at each end (as long as there aren't
any junctions or other reasons like changing attributes or features on the
road that require additional nodes), but when there are curves you can
obviously add endless nodes to approximate to the shape, and it will always
be smoother. In these cases I'd go with what the mapper has decided to put
and not simplify it automatically (as long as it is an improvement,
sometimes mappers draw many nodes so close but unprecise that the road gets
zigzag curvy because of missing precision, where it actually should be
smooth). In case of overnoding I suggest to improve the geometry manually,
because the douglas peucker algorithm that simplifies only by distance will
introduce problems in sharp curves/turns and leads to a loss of detail.

FWIW, any data consumer that needs simplified geometry can automatically
apply the algorithm and reduce the nodes by himself if that is what he
needs. Reducing is always easier, but enhancing detail automatically is not
possible.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] JOSM 9329, - Change default color of GPS tracks to magenta (r9248)

[Martin Koppenhoefer]

2016-01-08 10:30 GMT+01:00 Oleksiy Muzalyev :

> I like this change a lot. Now GPS tracks are clearly visible on the
> satellite image. I look at GPS tracks carefully in JOSM before going to
> mountains.



are you aware you can change all UI colours in JOSM in the settings? I've
for years been using a neon-green as that's providing nice contrast on the
aerial images in my area (and also against the osm objects in standard
style).

I wish it could be possible to view GPS tracks in magenta color as a map
> layer at the main OSM page, and also in mobile applications, especially
> like MAPS.ME, which allow to download a map (often no Internet access in
> mountains).



maps.me have their own issue tracker on github


> It would be a potentially life-saving feature.
>


exaggeration ;-)
everything could be potentially life-saving, it depends on the particular
circumstances.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Using native social SDK for signing in to OSM on mobile

[Martin Koppenhoefer]

sent from a phone

> Am 26.12.2015 um 12:33 schrieb Oleksiy Muzalyev :
> 
> On the photo of the hamlet Salin however it is clearly visible that it is 
> separated from the Route des Ormonts by the deep ravine, which requires 
> special equipment, training and many hours to cross.


clearly something an ideal map would show you more prominently than a photo 
ever could

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Why is ford=yes not rendered in the default style?

[Martin Koppenhoefer]

2015-11-26 10:57 GMT+01:00 Gerd Petermann :

> I know we should not map for the renderer, but why is
> the deprecated and rarely used highway=ford
> rendered with a nice icon on https://www.openstreetmap.org
> while the much more often and documented
> ford=yes is not ?
>


because currently in the rendering DB the highway key is available while
the ford key is not.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Duplicated "vor" in history

[Martin Koppenhoefer]

2015-11-04 17:22 GMT+01:00 Andy Townsend :

> (somewhat offtopic but) I'd be happy if we got rid of this "Ended about 1
> year ago" form altogether and just had something like "End Date: -mm-dd
> hh:mm".



+1, we could keep the generalized human form as a tooltip / hover for those
not on touch devices.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] New Map Style feedback

[Martin Koppenhoefer]

2015-11-02 20:02 GMT+01:00 Holger Jeromin :

> I do not care if the road is a motorway or trunk if this road is
>  the only large road into a city.
>


what might change instantly if motorways were to cost money to use them,
and other roads not. FYI, motorways are toll roads in most countries of the
world.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] New Map Style feedback

[Martin Koppenhoefer]

2015-11-02 10:33 GMT+01:00 Simon Poole :

> Which
> interesting enough however doesn't use every imaginable colour for their
> road network either
>
> https://www.ordnancesurvey.co.uk/osmaps/#53.00818632749056,-1.4402046835289466
> and essentially only differentiates between three road types.
>



and creates misleading / very hard to read situations like this (confusion
motorway/rivers):
[image: Inline-Bild 1]

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] New Map Style feedback

[Martin Koppenhoefer]

2015-11-02 10:51 GMT+01:00 Simon Poole :

> -1 given that you can always find specific situations in which a one
> size fits all rendering fails, in the previous style there are tons of
> while blobs made out of residential class roads, didn't stop anybody
> from using the map.
>



examples? IMHO, a residential road has to have some minimum width, a 2
metres wide alley (total width, no pavement) in a historic town center
should be tagged as an alley, for instance. Similarly, a highway=pedestrian
should be a road that is pedestrianized, not a small footway/alley inside a
"pedestrian" zone.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] New Map Style feedback

[Martin Koppenhoefer]

sent from a phone

> Am 02.11.2015 um 09:40 schrieb Maarten Deen :
> 
> Teritary roads, being white, are all but unrecognizable. Looking at 
> motorways, trunk roads or primary roads, I can not tell one from the other, 
> except when I see two next to eachother.
> Furthermore, on high zooms, roads have gotten too fat. It makes the map look 
> bulky.


+1, especially tertiary roads now tend to merge into blobs, e.g. here: 
http://www.openstreetmap.org/#map=17/41.85901/12.49464

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] New Map Style feedback

[Martin Koppenhoefer]

sent from a phone

> Am 01.11.2015 um 18:26 schrieb Tom Hughes :
> 
> Should we have a French style and a US style and a Chinese style and...
> 
> I mean how exactly do you propose to decide which national styles should get 
> special treatment?


ideally we should cater for all local/regional/national particularities (at 
least those that can be generally understood), e.g. in the US road shields are 
important, in cities with an underground/metro system, the specific logo would 
be nice to have, the japanese have crossings labeled in a typical way, 

Color schemes for roads seem less important to me, but apparently the British 
are quite attached to their scheme, so why not (other map providers do indeed 
use a particular scheme there)

cheers 
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Migrating osm.org to vectors/Kartotherian

[Martin Koppenhoefer]

2015-10-30 10:52 GMT+01:00 Christoph Hormann :

> So far use of vector tiles seem to primarily
> have lead to the following effects:
>
> - improved tile serving efficiency
> - a larger bandwidth of style variations
> - tighter contraints in basic styling decisions beyond what is already
> imposed by the OSM data model
>


some additional points that come into mind:

- vector maps are consuming more energy to display (because have to be
calculated/rendered) -> problem on mobile devices, but also generally a
problem because every client has to spend energy on calculating the "same"
image (admittedly depends how many different styles there are, and how many
people are looking at them until the underlying data changes), so globally
(i.e. wikipedia use and not some "niche" usecases) this means really a lot
of wasted energy.

- are likely slower to display (for the same reason), although this is
depending on different factors (e.g. if you have internet connection and
how fast it is (vector maps likely scale better for offline use), how
complex the style sheet is, etc.) -> generally vector maps require more
ressources, newer more capable client devices.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] taginfo not always as up to date as it says

[Martin Koppenhoefer]

2015-10-22 9:14 GMT+02:00 Gerd Petermann :

> claims to show data from  2015-10-21 23:58 UTC
>
> This looks wrong, as the numbers for highways are exactly the same as the
> day before
>
> when it showed
>
>  2015-10-20 23:58 UTC
>

\o/
Looks as if we're finished. Everything mapped!

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Duplicated "vor" in history

[Martin Koppenhoefer]

2015-09-29 18:23 GMT+02:00 Andy Townsend :

> On 29/09/2015 16:50, Martin Koppenhoefer wrote:
>
>> btw.: is there a way to see the actual date and time of a changeset in
>> the frontend, rather than an approximated natural language version?
>>
>
> Short answer - not as things currently stand.  For info, in case you've
> not seen them before:
>


Thanks for this summary, I think I had seen them before but forgot about it
in the meantime. Hovering is working fine here on the PC, but it is
unfortunately not working on the smartphone (naturally).

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Duplicated "vor" in history

[Martin Koppenhoefer]

btw.: is there a way to see the actual date and time of a changeset in the
frontend, rather than an approximated natural language version?

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] .bpg tiles

[Martin Koppenhoefer]

2015-03-17 12:21 GMT+01:00 andrzej zaborowski :

> Hi,
>
> BPG is an image format by Fabrice Bellard that was in the news a few
> months ago as "the JPEG replacement".  Its lossy compression mode
> seems to work well for OSM tiles because the artifacts are of a
> different type than in JPEG.  Here are some results for a small test
> area for different compression ratios (percentages of size saved
> against PNG).
>
>

Thank you for pointing to this.



> 51% at default level (-q 28) -- I could see no artifacts in the test area
>
> 62% at -q 32 -- minor deterioration can be seen, you can browse a
> small area at c.tile.openstreetmap.pl/viewer.bpg.xhtml
>


I can see some aliasing e.g. in the casing, but am not sure if this is from
the rendering or the compression, it would be useful to have a direct
comparison (i.e. the same tiles in png and bpg and maybe also jpeg).

This is announced as jpeg replacement, so I guess lots of colours are not a
problem? When using sat-images, hillshading or other kinds of gradients
(e.g. from blurring or rastersymbolizer) you will get a lot of shades and
png will compress worse compared to the relatively few colours you get for
instance with the standard style.

Generally I think loosing image quality but saving 50% of space is likely
not a tradeoff that OSM wants to accept, or the tiles would already be
compressed in jpeg and not png.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM with Hadoop

[Martin Koppenhoefer]

2015-02-18 11:46 GMT+01:00 Imre Samu :

> "WE JUST IMPORTED THE WORLD. AND ITS HISTORY. IN 47 MINUTES."   [ 30
> novembre 2013 ]




yes, but before we get too enthusiastic, they supposedly did it on this
machine:
"Our main database here is a 8 nodes (384 GB RAM, 96 CPU cores, 96 hard
drives and 96 database segments) Greenplum 
cluster. "

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Chinese spam diaries, an analysis

[Martin Koppenhoefer]

2014-12-03 17:14 GMT+01:00 Andy Allan :

> Thanks for the analysis, I hope it provides developers with ideas for
> combatting it via the automated spam filters that we already have[1].
>
> However, spam is an arms race, and I think we might need a different
> long-term approach. I know in the past using 3rd-party spam filtering
> services was too expensive (and not really very OSM-ish either).
> Perhaps we need a new set of human content moderators on the site, say
> 40-80 people with a variety of languages between them. We can consider
> grey-listing all accounts - i.e. the first few posts of every account
> is held for review automatically by default, and enable direct posting
> after we're more certain they aren't a spammer.
>



maybe we could have a crowd-sourced approach and introduce a "spam"-flag
that logged-in users could set, i.e. another button in the "comment",
"reply" line which says something like "flag as spam", with a counter, and
if more than x people have clicked on it we would automatically or manually
hide/delete the post. This should work similar to our stackexchange-like
helpsystem (you can flag or unflag with the same button).

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [OSM-talk] Release openstreetmap-carto v2.23.0

[Martin Koppenhoefer]

2014-10-29 21:34 GMT+01:00 Matthijs Melissen :

> * The tag shop=mall is now rendered like landuse=retail.



There have been, in recent discussions, concerns about this tag, as a mall
is not a shop.

https://www.mail-archive.com/tagging@openstreetmap.org/msg19626.html

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Traps in vector mapping

[Martin Koppenhoefer]

2014-10-18 22:23 GMT+02:00 Sandor Seres :

> Any vector smoothing algorithm (no matter if distance based, surface
> based, corridor based …) inherently moves slightly the line geometry
> nodes/vertices. So, if adjasent area fractions are processed independently,
> a common border section after the smoothing may result in slightly
> different poly-line section.



yes, the solution would be a fully topological model where you can simplify
connected geometries _together_ not independently (i.e. you'd simplify the
common border one time and use it for both adjacent areas).

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Contributing to OSM/Overpass

[Martin Koppenhoefer]

2014-07-08 15:36 GMT+02:00 Sachin Dole :

> offtopic newbie question: what is a "clickable" poi?



the idea is that you can click directly on some spot on the map and get
additional information (the tags of the clicked object) like opening_hours
or website link or the route relations a road segment is in etc.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Set configurations in JOSM advanced preferences

[Martin Koppenhoefer]

2014-06-18 15:09 GMT+02:00 amrit karmacharya :

>
> Is it okay if i add it myslf?
>


yes, you can add values that aren't there and it will (sometimes ;-) ) work.

As a sidenote you shouldn't use the simplify way functions on other stuff
on osm.org than those that you entered yourself (IMHO), or in other words,
use it with great caution (it will most probably create more harm then well
if the mapping was sensible before). It will remove nodes that create very
gentle curves / minor deviations from straight lines that do exist also in
reality, etc and will eliminate fine detail that should be there instead.
Please be aware that this function (douglas-peucker-algorithm) isn't aware
of angles but only of delta distances (causing it to "fail" in the case of
very sharp curves for instance).

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Moving to stricter multipolygon parsing

[Martin Koppenhoefer]

2014-06-13 1:25 GMT+02:00 Paul Norman :

> I think we need to move to a more strict parsing of MPs, accepting only
> new-style MPs and old-style MPs where all outers have identical
> non-deleted[2]
> tags and the relation itself has no non-deleted tags.
>


+1

There is really only one usecase where I abuse the fuzziness of the old
style: urban squares. While you often can't walk on all of their surface
(e.g. there might be a fountain, a sculpture, buildings, green, etc. to
exclude from highway pedestrian) the name will usually be for all of it.
Adding only a name also doesn't solve it, because then it is not clear
which kind of name it is (typology). This isn't really solved with old
style MPs neither, of course, but at least this is less obvious and might
be interpreted correctly by a human ;-)
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM based replacement for builtup_area.shp in standard style

[Martin Koppenhoefer]

> Am 03/giu/2014 um 20:23 schrieb Frederik Ramm :
> 
> I doubt that; I think people are adding place=* to boundary relations


I have also noticed this in various occasions, while this is mostly/often 
"wrong" for whole settlements (they tend to have bigger administrative areas 
around them than the actually developed space, unless they are in very dense 
contexts and the end of one is the beginning of the next), it is often the 
right thing to do for settlement parts like quarters.

Didn't dig deeper into the issue about actual percentages of the different 
styles, but I know from discussions on the lists that there are at least a few 
examples of place areas on their own (this is a field where many mappers will 
delete your tag on an area because they'll say that it's duplicating data, and 
as the node gets rendered but the area not it is clear to them that the area 
must go).

cheers,
Martin 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] OSM based replacement for builtup_area.shp in standard style

[Martin Koppenhoefer]

2014-06-03 18:46 GMT+02:00 Christoph Hormann :

> This is of course a fairly ressource intensive process with all building
> and road data in the database being used as basis.  But in principle it
> would be possible to run this with periodic updates in a similar way as
> currently done for the coastline.
>
> Everyone feel free to try out these polygons in your maps.  I have not
> tried this myself in the standard style yet, it is likely that
> adaptations in either the generalization process or the style (or both)
> are necessary for best results.  Comments and examples on that are
> welcome.
>


First of all I really appreciate the work and dedication you have invested
into this topic. Using external datasets from natural earth data has helped
us in the beginning of the project to produce better maps, but it is IMHO
clearly desirable to move these few uses in the future to osm-only derived
datasets. Your blog post and process is for sure an important contribution
to this discussion.

As a sidenote I wanted to point out that there are currently already 281547
ways (I suspect most of them to represent areas) tagged with place=* (not
much compared to a total of 3.1M places in OSM) which could serve as an
alternative to your (preprocessing intensive) process if more mappers could
be convinced for this concept of mapping settlement extensions.

The reasons why settlements mostly aren't mapped as areas lie mainly in the
current main map style sheet (read: "mapnik"), which ignores places on
areas due to technical limitations and because the place-nodes are needed
for routing and label placement, something that might change with the
progress of the project and new ways of structuring the data (e.g.
place-nodes and place-areas could co-exist, with appropriate rules how to
avoid redundancy, e.g. a place-relation combining the two and getting the
tags, the place-node could get the role "centre" or "central_point" or
"label"...). Currently doing both, place on an area and on a node, is
perceived as "duplication" and violation of the "one feature, one
object"-rule, but this is really just a question of definitions (e.g. the
node could be called "place centre" and the area "place extension"). I
think it is obvious that a node will never be the best representation for
something as large as a settlement (go and ask the Nominatim coders ;-) ).

The main problems of your approach --- it is still only "guessing" and the
derived dataset might have a high probability to identify "built-up" areas
but it will not in all cases be able to tell which settlement an area
belongs to and it is a ressource intensive process that reasonably cannot
be done on the fly --- could be overcome with explicit place polygons. On
the downside it will of course take us quite some time to manually map all
those settlements, and it is not even clear if people are interested in
general to map this kind of feature (in addition to landuse etc.). If the
main style picked this up and rendered areas with
place=(city,town,village,hamlet,isolated_dwelling) as "built-up-area" this
would surely help promoting the cause ;-)

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] osm.org not included in ssl-cert

[Martin Koppenhoefer]

If you go to https://osm.org you get a security warning because this site
is not included in the cert:

it says something like:
certificate only valid for *.openstreetmap.org,
openstreetmap.org(errorcode: ssl_error_bad_cert_domain)

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Nominatim geocoding for Japanese address

[Martin Koppenhoefer]

2014-04-10 17:06 GMT+02:00 Satoshi IIDA :

> > Taginfo reports that there are more addr:block_number than
> addr:blocknumber
> > but that might be unrelated.
>
> "addr:blocknumber" is used in Japan, and
> "addr:block_number" is used in Philippine.
> (only here http://overpass-turbo.eu/s/32h)
>
> IMHO...
> "addr:block_number"(PH) is not documented & discussed & used in 2 month.
> Hence, "addr:blocknumber"(JP) is a few used but be discussed a bit well.
> (from my view...)
>
> It may, perhaps be possible to change "addr:blocknumber"(JP) to
> "addr:block_number"(PH) by telling Japanese mappers.
> Your thought?
>


yes, I'd suggest that you discuss this and if you can reach consensus,
change the docu to addr:block_number (if the usage is the same, you should
ask the Philippine comunity about this). There are only ~200
addr:blocknumber but ~5000 addr:block_number currently in the database.
Also blocknumber does not seem to be English, but block number seems to be
(according to a google search).

If the usage / definition is not the same, you should still change the tag,
because if 2 tags are so similar, it will create a lot of confusion.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] mod_tile PID file

[Martin Koppenhoefer]

> Am 02/apr/2014 um 02:19 schrieb Troy Wu :
> 
> I'd appreciate hearing thoughts on this.


have a look at tirex rather then renderd

cheers,
Martin

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

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Martin Koppenhoefer]

2014/1/8 Pierre Béland 

> The images in the Highway tag usage wiki page give implicitely
> instructions to take care of the quality of the road to classify. But it is
> stated at the beginning of the page, that it is sometimes useful to adapt 
> *highway
>  tag usage* to the local
> physical conditions.
>


yes, we could remove the images altogether or complement them with
different ones from different regions in order to put them into context.
Lets discuss this in tagging.

Btw.: there was also a voting about the highway system (physical vs. grid
hierarchy):
https://wiki.openstreetmap.org/wiki/Proposed_features/Highway_key_voting_importance
and this is still reflected in the definition: "The *highway tag* is the
main tag used for identifying any kind of road, street or path. The highway
type helps indicate the importance of the highway within the road network
as a whole."

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Martin Koppenhoefer]

2014/1/8 Pieren 

> However, I see some interest to have a specific documentation for
> Africa.
>


agreed. FYI, I have changed the description on this page for tracks
(before: connection roads between hamlets, after: agricultural and forestry
use only). Be it in Africa or not, if a road has connection functionality
it can't be a track!



> The highway main doc is very european centric. But this
> discussion should continue on the tagging list.
>


+1, please follow ups on "tagging"

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Martin Koppenhoefer]

2014/1/8 Greg Troxel 

> First, set motorway aside.  We know what the motorway rules are, and all
> motorways are important (to first order).
>


+1



> Then, in a non-motorway
> world, you can ask "what is the shortest typical distance for which many
> routes will use this road".  Essentially, I'd argue that (if one decides
> to not use motorways), primary highways are likely to be the roads
> chosen for distances of 200km or more.   Secondary for perhaps 50 km,
> and many of the roads that feel like they should be tertiary are used to
> get to the next town, or next next town, but not 10 towns (except as
> local feeders, not a through route).  So that's more like 20 km.
>


no, if there is a primary road this doesn't mean that you cannot or won't
take it for shorter distances, usually you would take it (and often there
won't be alternatives anyway, especially in less developed countries) for
any distance as long as it goes where you want to go. The point of a
primary road is, that it allows you to go more far away if you need to,
while a tertiary road won't be hundreds of km long.




>
>   My sense is that a
> road is properly tertiary if it takes you from one place of 5000 people
> to another place of 5000 people.
>


ok, but this depends a lot of the population density in the area. A place
of 5000 people in Greenland would be the second biggest place of the
country. There are even some towns in Italy or Germany that have below 5000
inhabitants and everything above 100.000 is quite big there, but a town
with 300.000 inhabitants in China won't be big at all.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Martin Koppenhoefer]

2014/1/8 Pierre Béland 

> In this particular case, if there was a hierarchy of roads, it would be
> less a problem if the rule that I proposed was followed. See
> https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa
>


I don't understand this page. Not that I had objections with what I read
there, but it is a duplication of what is already set. Why "Africa"? We
should have (and do have) a global system to tag and classify roads,
bridge=yes and layer=1 are nothing special to Africa, neither is a
hierarchical road system. My suggestion is to delete the page or link to
the specific pages in to keep the wiki maintainable. Duplicating the same
information over and over again has no sense and raises the risk for
inconsistencies.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Renderer issue: highway=service and service=driveway?

[Martin Koppenhoefer]

> Am 06/gen/2014 um 14:58 schrieb Nick Whitelegg :
> 
> On the other hand I would probably make service roads appear on the same zoom 
> level as footpaths otherwise you're going to get "disappearing footpaths" 
> like this if a footpath follows a service road.


service roads are there, it is only the driveways which are (deliberately I 
guess) rendered only in high zooms.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] User Testing OSM.org

[Martin Koppenhoefer]

2013/12/7 Ian Dees 

> I am also interested in getting from this list some questions or topics we
> should be sure to cover. Is there some hypothesis you've had about how new
> users use the site that you'd like to have tested? Is there some piece of
> the site that feels too technical or too "newbie friendly"?
>


It would be interesting to see newbies interact with the more complex
mapping situations, where relations are present (of the types
turn_restriction, multipolygon, route and maybe site). Will the relations
break, or do the mappers hesitate to modify complex situations? Can our
current tools make them aware about what is in OSM and evventually warn if
there is risk of damaging this "more abstract" data or maybe handle it
transparently so that they can edit without damage and without being aware
for the relations?

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Change in osm interface and api

[Martin Koppenhoefer]

2013/12/1 amrit karmacharya 

> Since the change in osm interface today, i am not able to see the history
> of deleted objects like http://www.openstreetmap.org/browse/way/234627007
> .
>


this way id is probably not valid, look here:
http://www.openstreetmap.org/stats/data_stats.html

there have until now only
Number of ways 207127108
been created.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Upcoming website features

[Martin Koppenhoefer]

2013/10/21 Lauris Bukšis-Haberkorns 

> I will also agree malenski that top toolbar could be reduced a bit in
> height and also about page looks strange.



+1
I'd go as far as it shouldn't occupy more height than the current design (
29px)

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] have the table of contents vanished in the osm wiki?

[Martin Koppenhoefer]

Not sure if this is intentional or a bug, but it seems to me as if the
tables of contents have vanished from the key pages? Or is it a particular
problem on this page:
https://wiki.openstreetmap.org/wiki/Key:historic:civilization ? I can't
find the bug, but I'd bet that once that was different.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Start Contribution

[Martin Koppenhoefer]

2013/10/9 Akash Ashok 

> Oh So we dnt use POSTGIS extension ?? How do we store the geometries then
> like roads areas and location coordinates ?
>


not in the main db, but in the mapnik rendering db there is the postgis
extension enabled.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Start Contribution

[Martin Koppenhoefer]

2013/10/9 Pieren 

>
> We had in the past a diagram on this page:
> http://wiki.openstreetmap.org/wiki/Develop
>
> but is gone. Probably needs some refresh.



you can still find it in the history:
http://wiki.openstreetmap.org/w/index.php?title=Develop&oldid=812753

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Start Contribution

[Martin Koppenhoefer]

> Am 09/ott/2013 um 18:12 schrieb Akash Ashok :
> 
> Secondly my interest is mainly on the backend, POSTGIS, Routing Algos on top 
> of it etc... Now that i see there are quite a few components. What I'll do is 
> go thru the components and see what interests me and start picking up really 
> small tasks on those components.


it is also worth noticing that a lot of services are developed by third 
parties, e.g. there is no official routing but rather a lot of different 
projects all doing routing based on data offered by osm. There is a dev page in 
the wiki and some pages about projects based on osm, maybe you can find a 
starting point there.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Start Contribution

[Martin Koppenhoefer]

2013/10/9 Akash Ashok 

> 2. Is there a Jira page to know the list of outstanding issues that I
> could pickup ?
>


there is a trac-system with a collection of bugs and feature requests:
https://trac.openstreetmap.org/

I am not sure how suitable this is any more, as many (sub)-projects seem to
have moved to github in the last months. For josm there is a trac here:
http://josm.openstreetmap.de/

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] mapnik generate-xml.py creates local paths

[Martin Koppenhoefer]

After upgrade from ubuntu 11.04 to 12.04 (at least this is what I suspect
to be the reason) the generate-xml.py doesn't expand the filelocations to
absolute paths any more. I didn't touch anything there (I think), but now
instead of /home/user/mapnik/symbols/ there is just symbols/ and so on for
world_boundaries etc.
The script besides this works fine and includes the inc/ etc.

Any idea what might be the reason or how I could force the output to be
absolute paths?

thank you,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Linking wikipedia and osm

[Martin Koppenhoefer]

2013/9/6 amrit karmacharya 

> Thank you Eugene.
>
>  the 1st article   also didn't
> have the {{Coord}} template but it showed up. why is such difference?
>



actually the {{Coord}} template in WP is a different (parallel) approach,
it links an WP article to a certain (point) coordinate, while using the
wikipedia tag in osm links an OSM object to a wikipedia article. This is
not the same, and for features with a bigger extension (think of countries,
rivers, lakes, ...) it is far more useful to have the object linked instead
of a point coordinate.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [Mapcss] PGMapCSS 0.3.0

[Martin Koppenhoefer]

2013/9/3 Stephan Bösch-Plepelits 

> Another two busy weeks and already version 0.3.0 is available, which
> introduces a couple of very interesting features, noteably:
>
> * Link Selectors are supported, with a syntax similar to JOSM, e.g.
>   'rel[route=tram] >[role=stop] node[railway=tram_stop]'
>
> * There's a special link selector 'near' which matches objects in a certain
>   distance. E.g.
>   'area[landuse=cemetery] near[distance=0] node[historic=tomb]'
>   selects all tombs inside a cemetery.
>
> * Combine features: As streets in OSM are usually split into short parts
>   (because of changing type, e.g. one ways, count of lanes, ...) labels are
>   often missing or repeated too often. The statement 'combine' combines
>   selected features into one.
>
> There are some examples which illustrate these features:
> https://github.com/plepe/pgmapcss/blob/master/examples/README.md
>


awesome, that's really cool, this helps improve the cartography in a lot of
cases.

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Default map style on osm.org

[Martin Koppenhoefer]

Il giorno 28/ago/2013, alle ore 21:14, yvecai  ha scritto:

> There is no such formal decision.
> A user-oriented map style is not done because nobody has stand up to actually 
> do it, and have done it, simply.


there used to be one (osmarender tiles@home), but the crowd sourced rendering 
was not very efficient and had some limitations (xslt transformations of 
osm-xml without a db and spatial functions) and when the t@h maintainer finally 
resigned it wasn't continued. That style was particularly ugly in high zoom 
levels, but it was interesting and showed much more stuff than the mapnik of 
these days...

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Is the changeset view broken?

[Martin Koppenhoefer]

2013/7/31 Martin Koppenhoefer 

> I just noticed something strange that I don't understand. I looked at this
> recent change set:
> http://www.openstreetmap.org/browse/changeset/7995797
>
> and all three ways that the changeset summary lists as deleted have
> already been deleted more than a year ago by other users.
>
> Any clue how this can happen?
>
>

sorry, forget about this, just noticed the changeset is from 2011. Reason
that I had assumed it was recent is that the user is a "new contributor",
but apparently he already was registered quite some time ago and had done
one edit...

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Is the changeset view broken?

[Martin Koppenhoefer]

I just noticed something strange that I don't understand. I looked at this
recent change set:
http://www.openstreetmap.org/browse/changeset/7995797

and all three ways that the changeset summary lists as deleted have already
been deleted more than a year ago by other users.

Any clue how this can happen?

cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Bug on userpage blocks received

[Martin Koppenhoefer]

it seems as if blocks received on the user page doesn't show the correct 
number, e.g. this user has at least 2 blocks but it says 1

http://www.openstreetmap.org/user/Themegamaster9000

http://www.openstreetmap.org/user_blocks

cheers,
Martin

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