上传iOS App地图应用需要坐标范围文件（蔡哲永） - 简书
上传iOS App地图应用需要坐标范围文件（蔡哲永）
最近AppStore在上传新应用的时候对于地图类的应用需要上传一个.geojson格式的文件，该文件是对区域作限制的文件，只有在该文件中规定的区域范围内才能下载该应用，否则是不能下载该应用的。
那问题来了，如何才能生成该格式的问价呢？下面我们来看一下如何生成该格式的文件和创建viewcontroller文件方式相同，右键new File
选择Resource第一个就是我们需要的文件如下图。
创建完成后需要在文件中设置支持下载的区域的经纬度坐标，如下图：
注意：（1）坐标位置第一个和最后一个必须相同，在这些坐标围成的区域是有效部分。
（2）创建geojson文件的时候，文件名必须使用系统默认创建的文件名。
没有最好，只有更好！说说这次的感受吧:
变得是打包时间减少到4小时(其中大部分时间还是xcode7或者是iOS9的原因),不变的是还是一如既往的坑!!
好了,废话不多说,下面讲讲如何将一个APP 发布到 苹果的app store!
在xcode7以前,用户是不能直接真机调试的,必须有开发者帐号才可以真机! xcode7出现后,用户可以直接把app 安装在自己的手机上面
1=====&首先你得向apple 支付99刀成为苹果的全平台开发者(xcode7以前,99刀只能开发iOS应用),他会把你的apple id变成开发者帐号,这是最最基础的
2=====&在xcode的preference里面填写你的开发者帐号
3=====&注册App ID，在Xcode中填写Bundle Identifier
　　　　在中新增一个APP ID,他是专门属于你的这个应用的
---------------------------我是华丽的分割线-------------------------
bundle id 一般写com.你的公司名.应用名!
然后continue
---------------------------我是华丽的分割线-------------------------
然后打开XCode，选择Target & Summary。在Identifier输入框中输入上面注册的Bundle Identifier。
---------------------------我是华丽的分割线-------------------------
4=====&创建发布证书（Distribution Certificate）
　　　　　　iOS应用都有一个安全证书用于验证开发者身份和签名
　　　　　　打开mac上的钥匙串,然后打开证书助理,选择从证书机构颁发证书
---------------------------我是华丽的分割线-------------------------
---------------------------我是华丽的分割线-------------------------
---------------------------我是华丽的分割线-------------------------
---------------------------我是华丽的分割线-------------------------
---------------------------我是华丽的分割线-------------------------
添加刚才创建的.CSR签名文件。
刷新页面，然后就可以下载证书了。下载后安装。
最后一步，打开Keychain Access。选中刚才安装的private key，选择菜单中的Export Item将私钥导出。将导出的私钥备份到一个安全的地方，以便以后重装了系统可以还原。(团队共用这一份)
5=====& 创建Distribution Provisioning Profile(俗称pp文件)
打开Provisioning Portal，选择Provisioning -& Distribution，选择添加一个新的profile。Distribution Method要选择App Store，App ID需要输入在前面申请的App ID。证书也要选择刚开始申请的.cer文件.提交后需要等一会儿再刷新这个页面。然后就可以下载和安装profile了。安装后profile会被添加到XCode。然后就可以不用管了
---------------------------我是华丽的分割线-------------------------
---------------------------我是华丽的分割线-------------------------
---------------------------我是华丽的分割线-------------------------
---------------------------我是华丽的分割线-------------------------
6=====&用Distribution Profile为应用签名
打开XCode，在Build Settings中选择Code Signing。在Release设置上选择刚才申请的Distribution Profile。
一定要选择生成目标为iOS device，然后点击Archiving开始打包应用。
点击Edit Schemes，将Archive设置为Release。
7=====&在iTunes Connect上传App
在上新建你的app(我就是忘了先新建(第7步和8步顺序相反),所以就导致了一只出错,报我的bundle id 不合法,弄了好久才知道我应该在iTunes connect先新建app才行)
　　　　　　　　
------------主要是下面这个---------------
---------------------------我是华丽的分割线-------------------------
8=====&打包App
这样就可以把本地的app 添加到connect中了,然后就可以构建了
然后把这一页的信息填写正确后就可以提交了(很多坑!!! )
再说这次提交时因为xcode7或者ios9而导致的问题:
1).提交app store时,突然出现这个错误(xcode7以前从来没有遇到,不知道是不是xcode7或者ios9的锅)
搜索到的技术文章说有三种情况可能会导致这个问题:
　　1.检查启动图片是不是.png格式的
　　2.Put those images at root level of your project
　　3.放置一张启动图片命名为"Default-568h@2x.png",大小是640 & 1136 pixel的放在你的工程根目录下
我的app就是这样解决这个问题的
2).在iTunes connect里面填写信息的时候,APP图片不合法,首先必须要求大小是的
造成的原因是你的图片有圆角
解决方法是先用画图工具把它另存为.jpg格式的，然后再把它转换成.png格式的(也可以不用转)
解决问题！
3).在iTunes connect里面填写截图信息的时候,截屏图片不合法(这里是我手动更改的像素,太痛苦了,再也不想弄了...)
必须要求你的尺寸为:
3.5 &640 x 960&
4.0 &640 x 1136&
4.7 &750 x 1334
5.5&1242 x 2208&
ipad 1024 x 768&
阅读(...) 评论()This driver implements read/write support for access to features encoded in
format. GeoJSON is a dialect based on the
. JSON is a lightweight
plain text format for data interchange and GeoJSON is nothing other than its specialization for geographic content.
GeoJSON is supported as an output format of a number of services:
The OGR GeoJSON driver translates GeoJSON encoded data to objects of the :
Datasource, Layer, Feature, Geometry.
The implementation is based on .
Starting with OGR 1.8.0, the GeoJSON driver can read the JSON output of Feature Service requests following the
implemented by .
Starting with OGR 2.0, the GeoJSON driver can scroll through such result sets that
are spread over multiple pages (for ArcGIS servers &= 10.3). This is automatically enabled
if URL does not contain an explicit resultOffset parameter. If it contains
this parameter and scrolling is still desired, the FEATURE_SERVER_PAGING open option must be set to YES.
The page size can be explicitly set with the resultRecordCount parameter (but
is subject to a server limit). If it is not set, OGR will set it to the maximum
value allowed by the server.
Starting with OGR 1.11, the GeoJSON driver can read the
Starting with GDAL 2.1.0, the GeoJSON driver supports updating existing
GeoJSON files. In that case, the default value for the NATIVE_DATA open option
will be YES.
Datasource
The OGR GeoJSON driver accepts three types of sources of data:
Uniform Resource Locator () - a Web address to
Plain text file with GeoJSON data - identified from the file extension .geojson or .json
Text passed directly and encoded in GeoJSON
A GeoJSON datasource is translated to single OGRLayer object with pre-defined name OGRGeoJSON:
ogrinfo -ro http://featureserver/data/.geojson OGRGeoJSON
It's also valid to assume that OGRDataSource::GetLayerCount() for GeoJSON datasource always returns 1.
Starting with GDAL 2.2, the layer name is built with the following logic:
If a "name" member is found at the FeatureCollection level, it is used.
Otherwise if the filename is regular (ie not a URL with query parameters), then
the filename without extension and path is used as the layer name.
Otherwise OGRGeoJSON is used.
Accessing Web Service as a datasource (i.e. FeatureServer), each request will produce new layer.
This behavior conforms to stateless nature of HTTP transaction and is similar to how Web browsers operate:
single request == single page.
If a top-level member of GeoJSON data is of any other type than FeatureCollection, the driver will
produce a layer with only one feature. Otherwise, a layer will consists of a set of features.
If the NATIVE_DATA open option is set to YES, members at the level of the FeatureCollection will be
stored as a serialized JSon object in the NATIVE_DATA item of the NATIVE_DATA metadata domain of the
layer object (and "application/vnd.geo+json" in the NATIVE_MEDIA_TYPE of the NATIVE_DATA metadata domain).
The OGR GeoJSON driver maps each object of following types to new OGRFeature object:
Point, LineString, Polygon, GeometryCollection, Feature.
According to the GeoJSON Specification, only the Feature object must have a member with
name properties. Each and every member of properties is translated to OGR object of type of
OGRField and added to corresponding OGRFeature object.
The GeoJSON Specification does not require all Feature objects in a collection to
have the same schema of properties. If Feature objects in a set defined by FeatureCollection
object have different schema of properties, then resulting schema of fields in OGRFeatureDefn is generated as
of all Feature properties.
Schema detection will recognized fields of type String, Integer, Real, StringList, IntegerList and RealList.
Starting with GDAL 2.0, Integer(Boolean), Date, Time and DateTime fields are also recognized.
It is possible to tell the driver to not to process attributes by setting environment variable
ATTRIBUTES_SKIP=YES. Default behavior is to preserve all attributes (as an union, see previous paragraph),
what is equal to setting ATTRIBUTES_SKIP=NO.
If the NATIVE_DATA open option is set to YES, the Feature JSon object will be
stored as a serialized JSon object in the NativeData property of the OGRFeature object
(and "application/vnd.geo+json" in the NativeMediaType property). On write, if
a OGRFeature to be written has its NativeMediaType property set to "application/vnd.geo+json"
and its NativeData property set to a string that is a serialized JSon object, then
extra members of this object (i.e. not the "property" dictionary, nor the first 3
dimensions of geometry coordinates) will be used to enhance the created JSon object from
the OGRFeature. See
for more details.
Similarly to the issue with mixed-properties features, the GeoJSON Specification draft does not require
all Feature objects in a collection must have geometry of the same type. Fortunately, OGR objects model does
allow to have geometries of different types in single layer - a heterogeneous layer. By default, the GeoJSON driver
preserves type of geometries.
However, sometimes there is a need to generate a homogeneous layer from a set of heterogeneous features.
For this purpose, it's possible to tell the driver to wrap all geometries with OGRGeometryCollection type as a common denominator.
This behavior may be controlled by setting GEOMETRY_AS_COLLECTION=YES in the environment (default is NO).
Environment variables
GEOMETRY_AS_COLLECTION - used to control translation of geometries: YES - wrap geometries with OGRGeometryCollection type
ATTRIBUTES_SKIP - controls translation of attributes: YES - skip all attributes
Open options
(GDAL &= 2.0)
FLATTEN_NESTED_ATTRIBUTES = YES/NO: Whether to
recursively explore nested objects and produce flatten OGR attributes. Defaults to NO.
NESTED_ATTRIBUTE_SEPARATOR = character: Separator between components
of nested attributes. Defaults to '_'
FEATURE_SERVER_PAGING = YES/NO: Whether to automatically scroll through
results with a ArcGIS Feature Service endpoint.
NATIVE_DATA = YES/NO: (GDAL &= 2.1) Whether to store the native JSon representation at FeatureCollection and Feature level.
Defaults to NO. This option can be used to improve round-tripping from GeoJSON to GeoJSON by preserving some extra
JSon objects that would otherwise be ignored by the OGR abstraction. Note that
ogr2ogr by default enable this option, unless you specify its -noNativeData switch.
ARRAY_AS_STRING = YES/NO: (GDAL &= 2.1) Whether to expose JSon arrays
of strings, integers or reals as a OGR String. Default is NO. Can also be set with
the OGR_GEOJSON_ARRAY_AS_STRING configuration option.
To explain FLATTEN_NESTED_ATTRIBUTES, consider the following GeoJSON fragment:
"type": "FeatureCollection",
"features":
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [ 2, 49 ]
"properties": {
"a_property": "foo",
"some_object": {
"a_property": 1,
"another_property": 2
"ogrinfo test.json -al -oo FLATTEN_NESTED_ATTRIBUTES=yes" reports:
OGRFeature(OGRGeoJSON):0
a_property (String) = foo
some_object_a_property (Integer) = 1
some_object_another_property (Integer) = 2
POINT (2 49)
Layer creation options
WRITE_BBOX = YES/NO: (OGR &= 1.9.0) Set to YES to write a bbox property with the bounding box of the geometries at the feature and feature
collection level. Defaults to NO.
COORDINATE_PRECISION = int_number: (OGR &= 1.9.0) Maximum number of figures after decimal separator to write in coordinates.
Default to 15 for GeoJSON 2008, and 7 for RFC 7946. "Smart" truncation will occur to remove trailing zeros.
SIGNIFICANT_FIGURES = int_number: (OGR &= 2.1) Maximum number of significant figures when writing floating-point numbers.
Default to 17. If explicitly specified, and COORDINATE_PRECISION is not, this will also apply to coordinates.
NATIVE_DATA=string. (OGR &= 2.1) Serialized JSon object that contains extra properties to store at FeatureCollection level.
NATIVE_MEDIA_TYPE=string. (OGR &= 2.1) Format of NATIVE_DATA. Must be "application/vnd.geo+json", otherwise NATIVE_DATA will be ignored.
RFC7946=YES/NO. (OGR &= 2.2) Whether to use
initial version will be used.
Default is NO (thus GeoJSON 2008)
WRITE_NAME=YES/NO. (OGR &= 2.2) Whether to write a "name" property
at feature collection level with layer name. Defaults to YES.
DESCRIPTION=string. (OGR &= 2.2) (Long) description to write in a
"description" property at feature collection level. On reading, this will be
reported in the DESCRIPTION metadata item of the layer.
VSI Virtual File System API support
Some features below require OGR &= 1.9.0.
The driver supports reading and writing to files managed by VSI Virtual File System API, which includes
"regular" files, as well as files in the /vsizip/ (read-write), /vsigzip/ (read-write), /vsicurl/ (read-only) domains.
Writing to /dev/stdout or /vsistdout/ is also supported.
Round-tripping of extra JSon members
for more details.
Starting with GDAL 2.1, extra JSon members at the FeatureCollection, Feature or
geometry levels that are not normally reflected in the OGR abstraction,
such as the ones called "extra_XXXXX_member" in the below
snippet, are by default preserved when executing ogr2ogr with GeoJSON both at the
source and destination. This also applies to extra values in position tuples
of geometries, beyond the 3rd dimension (100, 101 in the below example), if the
transformation preserves the geometry structure (for example, reprojection is allowed, but not
change in the number of coordinates).
"type": "FeatureCollection",
"extra_fc_member": "foo",
"features":
"type": "Feature",
"extra_feat_member": "bar",
"geometry": {
"type": "Point",
"extra_geom_member": "baz",
"coordinates": [ 2, 49, 3, 100, 101 ]
"properties": {
"a_property": "foo",
This behaviour can be turned off by specifying the -noNativeData switch
of the ogr2ogr utility.
RFC 7946 write support
By default, the driver will write GeoJSON files following GeoJSON 2008 specification.
When specifying the RFC7946=YES creation option, the RFC 7946 standard will be
used instead.
The differences between the 2 versions are mentioned in
and recalled here for what matters to the driver:
Coordinates must be in longitude/latitude over the WGS 84 ellipsoid, hence
if the spatial reference system specified at layer creation time is not EPSG:4326,
on-the-fly reprojection will be done by the driver.
Polygons will be written such as to follow the right-hand rule for orientation
(counterclockwise external rings, clockwise internal rings).
The values of a "bbox" array are "[west, south, east, north]", not
"[minx, miny, maxx, maxy]"
Some extension member names (see previous section about round/tripping) are
forbidden in the FeatureCollection, Feature and Geometry objects.
The default coordinate precision is 7 decimal digits after decimal separator.
How to dump content of .geojson file:
ogrinfo -ro point.geojson
How to query features from remote service with filtering by attribute:
ogrinfo -ro http://featureserver/cities/.geojson OGRGeoJSON -where "name=Warsaw"
How to translate number of features queried from FeatureServer to ESRI Shapefile:
ogr2ogr -f "ESRI Shapefile" cities.shp http://featureserver/cities/.geojson OGRGeoJSON
How to translate a ESRI Shapefile into a RFC 7946 GeoJSON file:
ogr2ogr -f GeoJSON cities.json cities.shp -lco RFC7946=YES
Read the result of a FeatureService request against a GeoServices REST server:
ogrinfo -ro -al "/ArcGIS/rest/services/Hydrography/Watershed173811/FeatureServer/0/query?where=objectid+%3D+objectid&outfields=*&f=json"
- encoding geographic content in JSON
specification (obsoleted by RFC 7946).
- JavaScript Object Notation
- A JSON implementation in C
- driver announcement